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 <jmoell...@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@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@10:~> keyctl show -x > Session Keyring > 0x0e2f1b64 --alswrv 1000 65534 keyring: _uid_ses.1000 > 0x32af49bd --alswrv 1000 65534 \_ keyring: _uid.1000 > bor@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@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@10:~> keyctl show -x > Session Keyring > 0x2aeff9b2 --alswrv 1000 100 keyring: _ses > 0x2133e406 --alswrv 1000 65534 \_ keyring: _uid.1000 > bor@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@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@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) _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
