Re: [PATCH 00/19] gssd improvements

[Jeff Layton <jeff.layton@primarydata.com>]

On Thu, 11 Dec 2014 14:32:40 -0500
"J. Bruce Fields" <bfields@fieldses.org> wrote:

> On Thu, Dec 11, 2014 at 06:45:37AM -0500, Jeff Layton wrote:
> > For instance: module loading clearly needs to be done in the "context"
> > of the canonical root init process. That's what call_usermodehelper was
> > originally used for so we need to keep that ability intact.
> > 
> > OTOH, keyring upcalls probably ought to be done in the context of the
> > task that triggered them. Certainly we ought to be spawning them with
> > the credentials associated with the keyring.
> 
> Isn't the idmapping done as a keyring upcall?  You don't want ordinary
> users of the filesystem to be able to pollute the id<->name cache.
> 

Yes, it is done as a keyring upcall. You wouldn't need to allow random
users to pollute the cache. When you do a keys upcall the process gets
an authorization key that allows it to instantiate the key.

AFAIU, that's what guards against random processes polluting the
keyring, not any particular capabilities or anything.

> And in the gssd case, userland doesn't just find the right cred, it also
> does the rpcsec_gss context setup with the server.  A random user of the
> filesystem might not be able to do that part.
> 

I don't see why not. We already do that today as an unprivileged user
in gssd. process_krb5_upcall forks and changes identity before getting
a ticket and setting up the context and then handing that back to the
kernel. I don't think that requires any special privileges.

-- 
Jeff Layton <jlayton@primarydata.com>