[PATCH 2/2] KEYS: Add per-user_namespace registers for persistent per-UID kerberos caches

David Howells dhowells at redhat.com
Fri Aug 2 12:53:25 EDT 2013

Jeff Layton <jlayton at redhat.com> wrote:

> > +	/* -1 indicates the current user */
> > +	if (_uid == (uid_t)-1) {
> > +		uid = current_uid();
> Isn't it possible to have a valid uid of (unsigned int)-1? I know that
> at least some sites use that for "nobody". Why not just require passing
> in the correct UID?

See setresuid() and co. - there -1 is "don't change".

> Looks good overall, but I share Daniel's concerns about making
> krb5-specific infrastructure like this. Essentially this is just a
> persistent keyring that's associated with a kuid, right? Perhaps this
> could be done in such a way that it could be usable for other
> applications in the future?

It's not too hard, I suppose:

	keyctl_get_persistent(uid, prefix, destring)


	keyctl_get_persistent(-1, "_krb.", KEYCTL_SPEC_PROCESS_KEYRING)


	struct user_namespace
	  \___ .krb_cache keyring
		\___ _krb.0 keyring
		\___ _krb.5000 keyring
		\___ _krb.5001 keyring
		|	\___ tkt785 big_key
		|	\___ tkt12345 big_key
		\___ _afs.5000 keyring
			\___ afs.redhat.com rxrpc

The other way to do it is create one keyring per user and let userspace create
subkeyrings under that:

	struct user_namespace
	  \___ .krb_cache keyring
		\___ _uid_p.0 keyring
		\___ _uid_p.5000 keyring
		\___ _uid_p.5001 keyring
			\___ krb keyring
			|	\___ tkt785 big_key
			|	\___ tkt12345 big_key
			\___ afs keyring
				\___ afs.redhat.com rxrpc

In the above scheme, it might be worth just making these the same as the user
keyring - which means KEYCTL_SPEC_USER_KEYRING will automatically target it.

Simo:  I believe the problem you have with the user keyring is that it's not
persistent beyond the life of the processes of that UID, right?


More information about the krbdev mailing list