Differences between revisions 2 and 3
Revision 2 as of 2019-02-15 09:44:43
Size: 1919
Comment:
Revision 3 as of 2019-02-15 09:45:18
Size: 1969
Comment:
Deletions are marked like this. Additions are marked like this.
Line 9: Line 9:
 * Downloading packages
Line 10: Line 11:
 * Cleaning up packages

We'd like programs build using libapt-pkg to run as non-root users, with libapt-pkg automatically performing privileged operations as root.

Privileged operations in apt

  • Performing update
  • Setting options
  • Running scripts
  • Running json hooks
  • Downloading packages
  • Installing packages
  • Cleaning up packages
  • Locking

Concepts

State assertions

We need to ensure that user applications and the root daemon are in sync with each other in their view of the system, including, but not limited too:

  • Configuration settings, such as locations, and scripts to run
  • The state of the system / the cache.

The idea here is that when performing an operation via the privileged daemon, apt sends one or more state assertions that have to be validated by the daemon before it executes the operation.

For example, when executing ?RunScripts("foo") we have to send an assertion describing the state of the foo config list, to ensure that the daemon is really running the scripts we think it is.

When committing a change on the (dep)cache, we have to send an assertion describing the cache we have. A simple assertion here can be the hash of the cache: If the app and the daemon opened the same hash, we are good; otherwise, we have to reopen the cache in the app and recalculate the changes.

Locking

The proposal here is that the app can ask the privileged daemon to lock certain parts of the system while it's working. This would happen via PolicyKit and require some sort of authorization. This would ensure that updating tools can work reliably with a given system state and block others until they are done.

Handling lock termination in case of an app crash might be problematic: The idea here is that we have to notice when the app died. A simple idea might be to have the app send a pipe (opened in CLOEXEC) to the root daemon and then watch the pipe - if the app dies, the pipe will be closed.