On Tue, Jun 11, 2019 at 1:58 PM Josef Moellers <jmoell...@suse.de> wrote:
> On 11.06.19 12:45, Mantas Mikulėnas wrote: > > On Tue, Jun 11, 2019 at 1:08 PM Josef Moellers <jmoell...@suse.de > > <mailto:jmoell...@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: > That is not what I was talking about... > > 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". > Only if they do an explicit check for no good reason. AFAIK, other than the name, both kinds of keyrings otherwise behave identically from a program's perspective, and whenever the program asks for @s and there isn't one, the kernel just automatically substitutes @us. The only real issue is that programs won't be able to find *the actual credentials* that were added to a different 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. 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. -- Mantas Mikulėnas
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
