On Wed, 08 Aug 2012 19:45:33 +0200 Milan Knížek <knizek.confy@xxxxxxxxx> wrote: > Jeff Layton píše v Čt 19. 07. 2012 v 09:35 -0400: > > Many distros do not call into pam_keyinit to set up the session keyring > > properly at login time. When cifscreds add is used in such a session, > > the kernel will spawn a new session keyring in which to install the > > credentials. That keyring will then go away once the cifscreds process > > exits. > > How does one arrange that the session keyring is set up properly for > various login methods? > > I added "session optional pam_keyinit.so force revoke" > into /etc/pam.d/login and /etc/pam.d/sshd and "cifscreds add" works fine > when logged in console (alt+f2) or via ssh. > Session Keyring > 812231719 --alswrv 1001 100 keyring: _ses > 132272983 --alswrv 1001 -1 \_ keyring: _uid.1001 > 1046511393 ----sw-v 1001 100 \_ logon: cifs:a:192.168.1.3 > > > pam_keyinit.so was already in /etc/pam.d/gdm-password, though when > logged in into Xfce from GDM, then "cifscreds add" typed in > xfce4-terminal complains about non-persistent keyring. > > I can see that the name of the top level keyring differs for Xfce session: > Session Keyring > 666176370 --alswrv 1001 -1 keyring: _uid_ses.1001 > 132272983 --alswrv 1001 -1 \_ keyring: _uid.1001 > > Does anyone know if that is some GDM bug/feature and how avoid it? > > Sorry if being off-topic here, though I guess it might help others who > will run into the problems with cifscreds, too. > An excellent question. I see the same behavior on a fairly stock Fedora 17 host too. I can only assume that the actual desktop session is ending up with a different keyring session than gdm had. -- Jeff Layton <jlayton@xxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
