Error communicating with dbus

[justbennet]

Describe the bug

This command fails if I issue it when I ssh directly to the remote system, whereas it succeeds if I ssh as a different user and then su to the user running the test.

Direct ssh as bennetsw

$ python -c "import keyring; keyring.set_password('system', 'username', 'password')"
[bennetsw@gls8-build ~]$ python -c "import keyring; keyring.set_password('system', 'username', 'password')"
Traceback (most recent call last):
  File "/home/bennetsw/.local/lib/python3.6/site-packages/secretstorage/util.py", line 46, in send_and_get_reply
    return self._connection.send_and_get_reply(msg, unwrap=True)
  File "/home/bennetsw/.local/lib/python3.6/site-packages/jeepney/io/blocking.py", line 140, in send_and_get_reply
    return unwrap_msg(msg_in)
  File "/home/bennetsw/.local/lib/python3.6/site-packages/jeepney/wrappers.py", line 214, in unwrap_msg
    raise DBusErrorResponse(msg)
jeepney.wrappers.DBusErrorResponse: [org.freedesktop.DBus.Error.UnknownMethod] ("No such interface 'org.freedesktop.DBus.Properties' on object at path /org/freedesktop/secrets/collection/login",)

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/bennetsw/.local/lib/python3.6/site-packages/secretstorage/collection.py", line 161, in get_default_collection
    return Collection(connection)
  File "/home/bennetsw/.local/lib/python3.6/site-packages/secretstorage/collection.py", line 44, in __init__
    self._collection.get_property('Label')
  File "/home/bennetsw/.local/lib/python3.6/site-packages/secretstorage/util.py", line 64, in get_property
    (signature, value), = self.send_and_get_reply(msg)
  File "/home/bennetsw/.local/lib/python3.6/site-packages/secretstorage/util.py", line 49, in send_and_get_reply
    raise ItemNotFoundException('Item does not exist!') from resp
secretstorage.exceptions.ItemNotFoundException: Item does not exist!

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/bennetsw/.local/lib/python3.6/site-packages/keyring/backends/SecretService.py", line 61, in get_preferred_collection
    collection = secretstorage.get_default_collection(bus)
  File "/home/bennetsw/.local/lib/python3.6/site-packages/secretstorage/collection.py", line 164, in get_default_collection
    'default', session)
  File "/home/bennetsw/.local/lib/python3.6/site-packages/secretstorage/collection.py", line 145, in create_collection
    raise PromptDismissedException('Prompt dismissed.')
secretstorage.exceptions.PromptDismissedException: Prompt dismissed.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/bennetsw/.local/lib/python3.6/site-packages/keyring/core.py", line 60, in set_password
    get_keyring().set_password(service_name, username, password)
  File "/home/bennetsw/.local/lib/python3.6/site-packages/keyring/backends/chainer.py", line 58, in set_password
    return keyring.set_password(service, username, password)
  File "/home/bennetsw/.local/lib/python3.6/site-packages/keyring/backends/SecretService.py", line 87, in set_password
    collection = self.get_preferred_collection()
  File "/home/bennetsw/.local/lib/python3.6/site-packages/keyring/backends/SecretService.py", line 63, in get_preferred_collection
    raise InitError("Failed to create the collection: %s." % e)
keyring.errors.InitError: Failed to create the collection: Prompt dismissed..

After logging in as a different user, and then /bin/su - bennetsw

$ python -c "import keyring; keyring.set_password('system', 'username', 'password')"'
$ echo $?
0

To Reproduce

Steps to reproduce the behavior:

Login into remote host with ssh, then run the command above to get the error. To cause the error to go away, login as a different user of the same system, then

$ /bin/su - realuser
$ python -c "import keyring; keyring.set_password('system', 'username', 'password')"
$

and it succeeds.

Expected behavior
The command should succeed in both circumstances.

Environment

Red Hat Enterprise Linux release 8.3 (Ootpa)
$ python --version
Python 3.6.8

$ pip3 install --user keyring keyrings.alt GitPython

$ pip3 list --user
gitdb (4.0.7)
GitPython (3.1.17)
importlib-metadata (4.3.1)
jeepney (0.6.0)
keyring (23.0.1)
keyrings.alt (4.0.2)
SecretStorage (3.3.1)
smmap (4.0.0)
typing-extensions (3.10.0.0)
zipp (3.4.1)

$ rpm -qa | grep "python3-.*dbus"
python3-slip-dbus-0.6.4-11.el8.noarch
python3-dbus-1.2.4-15.el8.x86_64
python3-pydbus-0.6.0-5.el8.noarch

$ pip list | grep keyring
keyring (23.0.1)
keyrings.alt (4.0.2)

$ keyring --list-backends
keyring.backends.fail.Keyring (priority: 0)
keyring.backends.chainer.ChainerBackend (priority: -1)
keyrings.alt.file.PlaintextKeyring (priority: 0.5)

Additional context

I am not the administrator of the system.

[mitya57]

No such interface 'org.freedesktop.DBus.Properties' on object at path /org/freedesktop/secrets/collection/login

This is a very strange error. Do you actually have any Secret Service daemon running on the system (e.g. gnome-keyring)? If no, I would expect a different response:

The name org.freedesktop.secrets was not provided by any .service files

which would make keyring skip this backend immediately. Can you check if you have /usr/share/dbus-1/services/org.freedesktop.secrets.service file present?

Also, even though this seems to be a bug somewhere, I recommend you reading this section of our README:

https://github.com/jaraco/keyring/blob/main/README.rst#using-keyring-on-headless-linux-systems

[justbennet]

Yes, we do have that.

$ cat /usr/share/dbus-1/services/org.freedesktop.secrets.service
[D-BUS Service]
Name=org.freedesktop.secrets
Exec=/usr/bin/gnome-keyring-daemon --start --foreground --components=secrets

Running gnome-keyring-daemon --unlock does not seem to help, and it simply passes back

SSH_AUTH_SOCK=/run/user/28050/keyring/ssh

[justbennet]

And, to reiterate, if I su to the same account, then all works as expected. So it seems to be some mismatch between the way ssh is setting things up and the way keyring thinks it should be, and the su separates the sessions sufficiently so keyring does the right thing.

Still trying to get the system administrator to install the RH provided python3-keyring, which might have an RH hack to fix this.

[justbennet]

We tried installing the keyring package as provided in RedHat 8 EPEL. Those did not seem to fix the issue.

[docrobotnik]

Same for SLES 15.1 and SLES 15.2

@mitya57:

Also, even though this seems to be a bug somewhere, I recommend you reading this section of our README:

--> Thank you for pointing to the manual. However, seems not to be helpful at all. Some more ideas?

@jaraco:
Since your labeling was from July: Is there really no one assigned? Or do you need more input?

[jaraco]

Is there really no one assigned? Or do you need more input?

This project doesn't have any dedicated staff to assign. We're all volunteers giving our best efforts with no service level agreement. mitya57 is our most prolific and knowledgeable contributor on the Linux domain, so if they don't have a solution, then, yes, we'll need more information, and you may need to root-cause the issue yourself.

The code is open-source, so it should be possible in theory to trace through the code and find where the expectation is missed. I'd maybe start with seeing if you can reproduce the issue outside of keyring (calling the APIs as keyring does directly) or if there's something about keyring's usage that's implicated in the failure.

Good luck!

[exikyut]

This surfaces readily in Google searches for this issue, so adding what worked for me, taken from https://rtfm.co.ua/en/what-is-linux-keyring-gnome-keyring-secret-service-and-d-bus/:

• Create an Xvnc session on the server and connect to it (I was just using openbox)
• Open a terminal (I just used xterm)
• Run

  export $(gnome-settings-daemon --start)
  systemctl --user import-environment DISPLAY XAUTHORITY
  dbus-update-activation-environment DISPLAY XAUTHORITY
  

• In the same terminal, run the command
• I specified a new keyring password and used Blowfish encryption as the GPG option failed. While doing this the command timed out in the background but the password prompts were still visible.
• Rerun the command
• It worked! :D