Skip to content

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).

Goal

  1. An admin must be able to install multiple competing providers, and select exactly one active provider via the system configuration.
  2. Users should be able to override the system default with their preferred provider choice.
  3. 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.

Proposal

SystemD

  1. A provider may install a SystemD .service unit file to allow activation of the provider via SystemD.
  2. The unit file must have a provider-specific name, for example: dbus-org.freedesktop.secrets.my-provider.service.
  3. The unit file must include an Alias=dbus-org.freedesktop.secrets.service clause in its [Install] section.
  4. The unit file may also specify an org.freedesktop.secrets.service alias (without dbus- prefix).
  5. 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.
  6. If a DBus activation file is installed, it should contain a SystemdService key 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>.

DBus

  1. A provider may install a DBus auto-activation file to allow activation of the provider via DBus.
  2. 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 /usr/share/<provider>/dbus/.
  3. The provider may install a symlink from /usr/share/dbus-1/services/org.freedesktop.secrets.service to 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.
  4. User-specific overrides may be installed as symlinks from ~/.local/share/dbus-1/services/ to the provider-specific activation file.

XDG Autostart

  1. XDG Autostart should not be used to launch the service provider backend directly.
  2. Instead, DBus or SystemD should be configured to launch the preferred provider on-demand or on system startup.
  3. If necessary, the auto-start script may launch the generic org.freedesktop.secrets.service backend, allowing the above configurarion to decide which provider will be used.

PAM

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 org.freedesktop.secrets.service provider.

General

  1. 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.
  2. User-specific configuration should not be installed unless the user requested it.
  3. User-specific configuration must be cleaned up when the provider is uninstalled.