dbus_init() hangs when called in a script that calls another instance via sudo --preserve-env about secretstorage

[mwhahaha]

It should be noted this works fine without sudo. It fails with sudo without --preserve-env like so:

a main()
a launch()
a dbus_init()
a subprocess
b main()
b launch()
b dbus_init()
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/secretstorage/__init__.py", line 37, in dbus_init
    connection = connect_and_authenticate()
  File "/usr/lib/python3.6/site-packages/jeepney/integrate/blocking.py", line 90, in connect_and_authenticate
    bus_addr = get_bus(bus)
  File "/usr/lib/python3.6/site-packages/jeepney/bus.py", line 53, in get_bus
    return find_session_bus()
  File "/usr/lib/python3.6/site-packages/jeepney/bus.py", line 42, in find_session_bus
    addr = os.environ['DBUS_SESSION_BUS_ADDRESS']
  File "/usr/lib64/python3.6/os.py", line 669, in __getitem__
    raise KeyError(key) from None
KeyError: 'DBUS_SESSION_BUS_ADDRESS'

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

Traceback (most recent call last):
  File "/home/centos/test/b.py", line 9, in launch
    bus = secretstorage.dbus_init()
  File "/usr/lib/python3.6/site-packages/secretstorage/__init__.py", line 43, in dbus_init
    raise SecretServiceNotAvailableException(reason) from ex
secretstorage.exceptions.SecretServiceNotAvailableException: Environment variable DBUS_SESSION_BUS_ADDRESS is unset

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/centos/test/b.py", line 17, in <module>
    launch()
  File "/home/centos/test/b.py", line 11, in launch
    raise RuntimeError("Unable to initialize SecretService: %s" % e)
RuntimeError: Unable to initialize SecretService: Environment variable DBUS_SESSION_BUS_ADDRESS is unset
a exception
Traceback (most recent call last):
  File "./a.py", line 29, in <module>
    launch()
  File "./a.py", line 21, in launch
    subprocess.check_call(cmd)
  File "/usr/lib64/python3.6/subprocess.py", line 311, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', 'python3', '/home/centos/test/b.py']' returned non-zero exit status 1.

[mitya57]

This is a quite exotic configuration…

My hypothesis is that:

• When you use sudo, the effective user id is 0, so Jeepney uses that for authentication.
• However if you also pass the --preserve-env, the DBUS_SESSION_BUS_ADDRESS is present in the new environment, so Jeepney uses that to connect to the bus.
• And probably connecting to a user's session bus when authenticated as a different user (root) does not work.

I'm not sure if this can be fixed at all, but if it can then the fix should be in Jeepney, not in SecretStorage. If I am wrong then pull requests are welcome.

[mwhahaha]

Just FYI this worked under 2.3.1. I'm not certain the best way to open issues against Jeepney :/

[mwhahaha]

I found the jeepney issue board. I'll open one over there as well. This isn't as exotic as you think because this is triggered simply by 'import keyring'

[takluyver]

To summarise the discussions on Jeepney: the hang seen on CentOS 8 is a bug in Jeepney, which I aim to fix by raising the same ConnectionResetError that already occurs on some other platforms.

keyring is meant to gracefully handle errors setting up the backend and disable it without crashing on import, and on my machine it does. See code here and here. So I believe that the crashes on importing keyring are/were a bug with that package.

[mitya57]

If https://gitlab.com/takluyver/jeepney/-/merge_requests/13 is merged then no changes are needed in SecretStorage or keyring. SecretStorage will convert ConnectionResetError to SecretServiceNotAvailableException, and keyring will catch that and treat the backend as not viable.

In case there is a new type of exception that jeepney can raise, I am fine with changing SecretStorage to intercept it.

[mwhahaha]

https://gitlab.com/takluyver/jeepney/-/merge_requests/13 resolves it as SecretStorage will bubble up the error which keyring handles.