[systemd-devel] keyrings and dbus

[Andrei Borzenkov]

11.06.2019 15:32, Josef Moellers пишет:
> On 11.06.19 13:27, Mantas Mikulėnas  wrote:
>> On Tue, Jun 11, 2019 at 1:58 PM Josef Moellers <jmoellers at suse.de
> 
>>     The point is that in the gnome-terminal case, pam_keyinit.so is not
>>     involved.
>>
>>
>> It is. The systemd --user instance (from which dbus-daemon and
>> gnome-terminal-server descend) has its own PAM stack and can call
>> pam_keyinit.so if needed.
> 
> Strange thing is, that it already does!
> 
> /etc/pam.d/systemd-user:
> session  optional       pam_keyinit.so force revoke
> 

I checked on vanilla Tumbleweed VM and systemd-user does not have
pam_keyinit. And yes, I observe exactly the same behavior you described.
Unfortunately things are more complicated:

bor at 10:~> cat /proc/keys
12cf2039 I--Q---    93 perm 3f030000  1000   100 keyring   _ses: 1
32af49bd I--Q---     1 perm 1f3f0000  1000 65534 keyring   _uid.1000: empty
bor at 10:~> keyctl show -x
Session Keyring
0x0e2f1b64 --alswrv   1000 65534  keyring: _uid_ses.1000
0x32af49bd --alswrv   1000 65534   \_ keyring: _uid.1000
bor at 10:~>


So there is user session keyring, but gnome-terminal (and any process
spawned by it) are not attached to it.

If I add pam_keyinit to systemd-user, I do get session keyring for gnome
terminal, but this is really wrong one:

bor at 10:~> cat /proc/keys
2133e406 I--Q---     2 perm 1f3f0000  1000 65534 keyring   _uid.1000: empty
2aeff9b2 I--Q---    67 perm 3f030000  1000   100 keyring   _ses: 1
3c18175c I--Q---    93 perm 3f030000  1000   100 keyring   _ses: 1
bor at 10:~> keyctl show -x
Session Keyring
0x2aeff9b2 --alswrv   1000   100  keyring: _ses
0x2133e406 --alswrv   1000 65534   \_ keyring: _uid.1000
bor at 10:~>

so now there are two session keyrings, some of processes (that for all
practical purposes *do* belong to the same user session) are attached to
one keyring, some to the other. Which makes it impossible to actually
use session keyring to share keys.

The first session keyring is created by gdm in this case (specifically
gdm-autologin), second - by systemd-user.

Technically this is probably correct - session keyring lifetime is
exactly that - session, and systemd-user lifetime is independent of
individual (GUI) login session lifetime. But then D-Bus should not be
started inside systemd-user "session", because lifetime of D-Bus user
instance is supposed to be the same as user login session. Or D-Bus
needs explicit support for passing session keyring information when
invoking user service that is part of user login session. Because now we
potentially have multiple login sessions sharing the same single D-Bus
instance and having different session keyrings with different lifetime ...

P.S. complete lack of introspection possibility for keyrings is really
frustrating. What created this keyring? Which processes are attached to
it? Etc ...

> So, even if a keyring exists, a new one user keyring would be created
> ("force"), but apparently none exists.
> 
> Josef
>