Re: [PATCH 00/19] gssd improvements

["J. Bruce Fields" <bfields@fieldses.org>]

On Thu, Dec 11, 2014 at 02:50:29PM -0500, Jeff Layton wrote:
> 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.

That doesn't stop it from instantiating the key with the wrong
information.

> > 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.

Why couldn't you give a task access to an nfs filesystem but wall it off
in a network namespace where it doesn't even have access to the
interface that the mount was done over?

(And similarly what's to guarantee that a user of the filesystem is
capable of doing the ldap calls you might need for idmapping?)

--b.