[systemd-devel] keyrings and dbus
Josef Moellers
jmoellers at suse.de
Thu Jun 13 08:11:27 UTC 2019
On 12.06.19 17:34, Andrei Borzenkov wrote:
> 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.
I stand corrected: I added it as part of checking whether that would
help ... which it doesn't.
> 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:~>
Not really ... if you look at the keyring IDs (in the first column) eg
in a gnome-terminal and in an xterm, you will see that both session
keyrings (the "session keyring" in the xterm and the "user session
keyring" in the gnome-terminal) link to the very same "user keyring":
Leap-15.1:
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
All three share the same "user keyring" with ID 105956722!
This is the single keyring the kernel maintains for the user ID 1000.
> 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.
If keys are attached to the "user keyring", then, indeed, they can (and
will) be shared as shown above!
>
> The first session keyring is created by gdm in this case (specifically
> gdm-autologin), second - by systemd-user.
What puzzles me at the moment is that I tried to reproduce this issue on
my Leap 15.1 VM and IT DOES NOT REPRODUCE ANY MORE:
josef at linux-7gwm:~> grep . xterm gnome-terminal
xterm:Session Keyring
xterm:0x1d40e70e --alswrv 1000 100 keyring: _ses
xterm:0x333d487a --alswrv 1000 65534 \_ keyring: _uid.1000
gnome-terminal:Session Keyring
gnome-terminal:0x3f058f6f --alswrv 1000 100 keyring: _ses
gnome-terminal:0x333d487a --alswrv 1000 65534 \_ keyring: _uid.1000
Both isnatances have, at the top, a "session keyring" and none has a
"user session keyring".
This is due to the pam_keyring invocation I added to
/etc/pam.d/systemd-user. When I remove that line (eg by commenting it
out), a "user session keyring" is created instead of the "session keyring":
josef at linux-7gwm:~> keyctl show -x
Session Keyring
0x3ba37617 --alswrv 1000 65534 keyring: _uid_ses.1000
0x0c90f0bf --alswrv 1000 65534 \_ keyring: _uid.1000
It appears as if the "systemd --user" caches the contents of the
"/etc/pam.d/systemd-user" file or maybe even runs through it only once
upon startup (of systemd --user).
you wouldn't know, perchance, if there are any other processes started
by the "systemd --user" instance of my user?
TL;DR
The addition of "session optional pam_keyinit.so force revoke" to
/etc/pam.d/systemd-user seems to fix my problem. The only question which
remains is if this has any adverse consequences.
Josef
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