[systemd-devel] keyrings and dbus

Josef Moellers jmoellers at suse.de
Tue Jun 11 10:58:39 UTC 2019


On 11.06.19 12:45, Mantas Mikulėnas wrote:
> On Tue, Jun 11, 2019 at 1:08 PM Josef Moellers <jmoellers at suse.de
> <mailto:jmoellers at suse.de>> wrote:
> 
>     Hi,
> 
>     We have seen this problem: when you open a gnome-terminal, then the
>     shell in that terminal will not have the same keyring (created by
>     pam_keyinit.so) as the one eg in an xterm. This is due to the fact that
>     the xterm ist started by the standard fork/exec mechanism which passes
>     the keyring down to the children and the gnome-teminal (actually
>     gnome-terminal-server) is started by sending a dbus message to some
>     instance which the starts the terminal process.
> 
>     AAMOF the gnome-terminal does not even have a keyring, so if one asks
>     for it ("keyctl show @s"), it is created on the fly. This causes the
>     kernel to create a keyring as a "user session keyring" while the GNOME
>     session (and thus the xterm) has a "session keyring".
> 
>     Has anyone seen this and/or, most important question, does anyone have
>     an idea how to solve this?
> 
>     I know that, strictly speaking, this is not a systemd question, but
>     we're trying to probe many sources to see if anyone has a solution.
> 
> 
> IIRC the usual advice by Lennart is to use the user-wide @u keyring
> instead of session keyrings. (Programs searching in @s should
> automatically find credentials added to @u, as pam_keyinit creates the
> link by default.)

Thanks Mantas,

It's not the fact that the user keyring is missing, which it isn't, but
it's the fact that a "user session keyring" rather than a "session
keyring" is produced:

ssh:
Keyring
  69871887 --alswrv   1000   100  keyring: _ses
 105956722 --alswrv   1000 65534   \_ keyring: _uid.1000
-> Session Keyring (_ses) linked to User Keyring (_uid.<UID>)

gnome-terminal-server:
Keyring
 219457014 --alswrv   1000 65534  keyring: _uid_ses.1000
 105956722 --alswrv   1000 65534   \_ keyring: _uid.1000
-> User Session Keyring (_uid_ses.<UID>) linked to User Keyring (_uid.<UID>)
   User Keyring is identical with User Keyring in ssh

xterm:
Keyring
 633373159 --alswrv   1000   100  keyring: _ses
 105956722 --alswrv   1000 65534   \_ keyring: _uid.1000
-> Session Keyring (_ses) linked to User Keyring (_uid.<UID>)
   User Keyring is identical with User Keyring in ssh
-end of output-

I'm not THAT familiar with the keyring mechanism, especially not with
the actualy usage of them, but I don't know if one application or the
other might later choke on the top level NOT being a "session keyring"
but a "user session keyring".

> You could probably alter pam_keyinit.so to allow joining an existing
> session keyring (which is IIRC possible in the API). That way your
> graphical sessions Ipam.d/gdm) would join the same @s created by systemd
> --user instance (pam.d/systemd-user), which is the same one used by
> dbus-daemon.

The point is that in the gnome-terminal case, pam_keyinit.so is not
involved. My assumption (which the gnome developers still need to
verify/reject) is that the receiver of the "start gnome-terminal-server"
message either does not have a keyring to start with OR is careful
enough to dispose of whatever keyring it has and then starts the
terminal server without any keyring.

Thanks again,

Josef
-- 
SUSE Linux GmbH
Maxfeldstrasse 5
90409 Nuernberg
Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)


More information about the systemd-devel mailing list