My ultimate goal is to get gnome-keyring functioning as a credential storage for use by shell and python scripts on an RHEL 6 server. The admins installed package gnome-keyring-2.28.2-8.el6_3.x86_64, and the gnome-keyring-daemon does start.

When I try to access it from Python though, I get an error The name org.freedesktop.secrets was not provided by any .service files

Googling for that error returns a number of issues that are solved by "install gnome-keyring", but that's been done on this system already.

I'm not sure if I'm looking at a config issue, or an ancient-version issue, or something else.

Edit: @grawity's answer adds quite a bit of clarity in general. I suspect you're right about gnome keyring, as what I'm doing is this:

launch gnome-keyring-daemon into a dbus session: dbus-run-session -- gnome-keyring-daemon --start


launch a shell into a dbus session: dbus-run-session -- bash


call python-keyring and have it list the backends it finds: pipenv run python -m keyring --list-backends


D-Bus .service files are necessary for automatic "on demand" activation of services. Some of them, however, aren't meant to be activated on-demand – instead they're meant to be launched explicitly by the desktop environment or by a PAM module or such. Once started this way, gnome-keyring-daemon will claim the bus name without needing a .service file.

The real issue is likely with the way programs connect to GNOME Keyring. It is not a system service; it is a per-user service, but it is accessible through the D-Bus "session bus", which as the name implies is usually per-session. (Although this has changed recently with many Linux distributions moving to the "user bus" model, but from the PoV of RHEL 6 that's still distant future.)

When gnome-keyring-daemon starts, it connects to what it sees as the "current" session bus (i.e. what's set in $DBUS_SESSION_BUS_SOCKET) and will claim a name on that bus. But if your other SSH sessions do not have this environment variable, they won't be able to find the correct bus (in the worst case they'll start a new session-bus instance every time).

So depending on the method you use to start gnome-keyring-daemon, you might want to manually start the dbus-daemon --session instance as well (using dbus-run-session or dbus-launch), and you need to make sure all SSH sessions belonging to that user know the same $DBUS_SESSION_BUS_SOCKET. For example, after launching the daemon you could store the environment variables in ~/.dbus.env which other SSH sessions automatically "source" from their ~/.profile and such.

For reference, if the daemon is started by pam_gnome_keyring (as it is with GNOME) and you are not using pam_systemd on this machine (which probably doesn't exist on RHEL 6), the initialization process has two stages and works like this:

  1. PAM goes through the 'open_session' stage and runs gnome-keyring-daemon --daemonize --login.
  2. The daemon opens a "control" Unix socket somewhere.
  3. The desktop environment starts a session bus via dbus-launch and exports $DBUS_SESSION_BUS_SOCKET to be available to all programs.
  4. The desktop environment calls gnome-keyring-daemon --start, which uses the control socket to inform the keyring daemon of the $DBUS… variable's contents.
  5. The keyring daemon connects to the session bus and claims the org.freedesktop.secrets bus name.
  • Thanks for this; I added information about the steps I was taking to my post if that sheds any light on what I'm doing wrong to get gnome keyring on the bus – Azide May 9 '19 at 13:17
  • Your edit shows that you're starting two completely separate dbus sessions? – user1686 May 9 '19 at 13:38
  • I guess I am (oops) -- but fixing that (I think) by doing dbus-run-session -- bash gnome-keyring-daemon --start pipenv run etc to keep it all in one session doesn't change the error I was getting. – Azide May 9 '19 at 13:55
  • I also just realized that /etc/pam.d/login doesn't have auth optional pam_gnome_keyring.so or session optional pam_gnome_keyring.so auto_start so might getting those added be a place to start? – Azide May 9 '19 at 13:56
  • How do you plan on unlocking the encrypted keyring? Will you want to use the system login password, or a separate password? – user1686 May 9 '19 at 14:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.