On Thu, 30 Jan 2014, David Howells wrote: > (5) Don't implicitly create a new anonymous keyring and don't implicitly set > the session keyring to the user-session keyring, but rather just fall > back > to using the user-session keyring if there isn't a session keyring. >
> > That said, I do think that the Kerberos people have a valid point. The > current > behaviour is poor. I'm inclined to implement (5) or (6), probably (5). > > This won't make any difference to most processes, ie.: > > (*) Those run from pam_keyinit-managed login shells. > > (*) Those that don't make use of libkrb5 or keyrings. > So there are existing apps which will see semantic changes? If so, we can't accept this change. > In many ways, I'd like to just get rid of the user and user-session keyrings > from the kernel entirely and have them created and maintained by pam_keyinit. > The special keyring IDs: > > KEY_SPEC_USER_KEYRING > KEY_SPEC_USER_SESSION_KEYRING > > and: > > KEY_REQKEY_DEFL_USER_KEYRING > KEY_REQKEY_DEFL_USER_SESSION_KEYRING > > would then search your session keyring for keyrings called "_uid" and > "_uid_ses" and return those. Unfortunately, I think this is probably a > much-too-big change at this point. > > Any thoughts? Getting it right is more important than the size of the change. What about creating a new system call with the desired behavior, and deprecating the current one (or at least, making it a wrapper for the new call). -- James Morris <jmor...@namei.org> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
