Secret-service: missing auto-start configuration instructions
The current spec is missing instructions on how a Secrets Service provider should configure Secrets Service auto-start in a manner that would not conflict with other providers. See keepassxc:6274 (note: it was misidentified as a SystemD configuration conflit; it's actually DBus configuration).
- An admin must be able to install multiple competing providers, and select exactly one active provider via the system configuration.
- Users should be able to override the system default with their preferred provider choice.
- Providers must "play nice" with other providers, avoiding configuration conflicts and other potential conflicts.
I'm not 100% sure that per-user configuration is necessary. But currently, the backends tend to be tied to the specific secrets DB file formats, which are in turn tied to each user's preferred password manager. So different manager -> different native file format -> different service backend.
- A provider may install a SystemD
.serviceunit file to allow activation of the provider via SystemD.
- The unit file must have a provider-specific name, for example:
- The unit file must include an
Alias=dbus-org.freedesktop.secrets.serviceclause in its
- The unit file may also specify an
- A symlink of the same provider-specific name should be installed in the
/usr/lib/systemd/user/folder, pointing to the actual file. This enables per-user activation.
- If a DBus activation file is installed, it should contain a
SystemdServicekey pointing to the corresponding provider-specific SystemD service.
The use of an
Alias clause ensures that only one
dbus-org.freedesktop.secrets.service provider can be activated by SystemD at any given time.
If a per-user service configuration is desired, the admin should disable the system-level provider with
systemctl --system disable dbus-org.freedesktop.secrets.service (as root). Then, the preferred service provider may be enabled as default for all users with
systemctl --global enable <service-provider> (as root). This may be overriden on a per-user level with
systemctl --user enable <service-provider>.
- A provider may install a DBus auto-activation file to allow activation of the provider via DBus.
- The activation file must have a provider-specific name, for example
org.freedesktop.secrets.my-provider.service, and/or be installed in a provider-specific folder, for example in
- The provider may install a symlink from
/usr/share/dbus-1/services/org.freedesktop.secrets.serviceto the provider-specific activation file. This should be configured via the alternatives system, if available (Debian, RHEL, etc). On systems where SystemD is available, the SystemD mechanism is preferred.
- User-specific overrides may be installed as symlinks from
~/.local/share/dbus-1/services/to the provider-specific activation file.
- XDG Autostart should not be used to launch the service provider backend directly.
- Instead, DBus or SystemD should be configured to launch the preferred provider on-demand or on system startup.
- If necessary, the auto-start script may launch the generic
org.freedesktop.secrets.servicebackend, allowing the above configurarion to decide which provider will be used.
TODO: The current API does not support unlocking the secrets DB with a known secret without a prompt. As a result, PAM modules that are used to unlock the secrets DB have to bypass the DBus API in a provider-specific manner. It may be desirable to extend the API to allow the
Unlock() method or a variant thereof to receive a known secret (see #74). Then, a set of generic PAM modules can be developed to unlock the DB via the configured
- A provider must refuse to run if another provider is already running. It should return a clear error message instructing the user to shut down the running provider first.
- User-specific configuration should not be installed unless the user requested it.
- User-specific configuration must be cleaned up when the provider is uninstalled.