Jeff Layton <[email protected]> wrote:
> On Wed, 11 Jul 2012 21:05:31 +0200
> Milan Knížek <[email protected]> wrote:
>
> > Jeff Layton writes:
> >
> > >> cifscreds add is more or less equivalent to a command like this:
> > >
> > > $ keyctl add logon cifs:a:ip_address 'username:password' @s
> > >
> >
> > There seems to be a general problem with adding keys (@s) to the default
> > "session" keyring. Adding user type keys (@u) works.
> >
> > $ keyctl add logon description data @s
> > does not add anything to the _uid_ses:UID keyring, which is automatically
> > created after login.
> >
> > Interestingly, when a new session keyring is added, then it works:
> >
> > [root@client ~]# su - zmrzlinka
> > [zmrzlinka@client ~]$ keyctl show
> > Session Keyring
> > 1037083570 --alswrv 1001 -1 keyring: _uid_ses.1001
The problem is here.
Your process here does not have its own session keyring. Instead it falls
back to the user-session keyring when it can (you can see this by the
"_uid.ses.<uid>" name on the keyring).
In the kernel, lookup_user_key() has special logic in the kernel for handling
the case where you try and modify the session keyring when you don't have one.
That includes adding a link into it to a new key:
case KEY_SPEC_SESSION_KEYRING:
if (!cred->session_keyring) {
/* always install a session keyring upon access if one
* doesn't exist yet */
ret = install_user_keyrings();
if (ret < 0)
goto error;
if (lflags & KEY_LOOKUP_CREATE)
ret = join_session_keyring(NULL);
else
ret = install_session_keyring(
cred->user->session_keyring);
if (ret < 0)
goto error;
goto reget_creds;
} else if (cred->session_keyring ==
cred->user->session_keyring &&
lflags & KEY_LOOKUP_CREATE) {
ret = join_session_keyring(NULL);
if (ret < 0)
goto error;
goto reget_creds;
}
lookup_user_key() is called with KEY_LOOKUP_CREATE set when the add_key()
system call invokes it to get the destination keyring. That means that a new
session keyring will be created for the cifscreds process (note the
join_session_keyring() calls) - and will be destroyed when that process exits.
Your system should call pam_keyinit from the login process to set up your
session keyring. This has been around for a few years, but not all
distributions choose to use it (as far as I can tell, Debian and Ubuntu fall
into this category).
On a Fedora-based system, you see:
[dhowells@andromeda ~]$ keyctl show
Session Keyring
222025610 --alswrv 4043 4043 keyring: _ses
60559872 --alswrv 4043 -1 \_ keyring: _uid.4043
The default name for the session keyring is _ses. Because processes on Fedora
have a session keyring allocated by PAM, this then works:
[dhowells@andromeda ~]$ cifscreds add www.redhat.com
Password:
[dhowells@andromeda ~]$ keyctl show
Session Keyring
222025610 --alswrv 4043 4043 keyring: _ses
60559872 --alswrv 4043 -1 \_ keyring: _uid.4043
4690765 ----sw-v 4043 4043 \_ logon: cifs:a:2.19.119.214
Note that the behaviour can be reproduced on Fedora by this:
keyctl session _uid_ses.<uid>
So, for me, I would do:
keyctl session _uid_ses.4043
which will create a new shell that has the user-session process as the session
keyring, which will then fail to work exactly as if there was no specifically
assigned session keyring:
[dhowells@andromeda ~]$ keyctl add user a a @s
341403701
[dhowells@andromeda ~]$ keyctl show
Session Keyring
961618603 --alswrv 4043 -1 keyring: _uid_ses.4043
60559872 --alswrv 4043 -1 \_ keyring: _uid.4043
David
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
