Re: [PATCH 00/19] gssd improvements

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

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.

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.

--b.

> 
> Today, those tasks not only run in the namespaces, etc of the root init
> process, but also with with root's creds. That's unnecessary and seems
> wrong. I think it's something that ought to be changed (though doing so
> will likely be painful as we'll need to change the upcall programs to
> handle that).
> 
> There are also other questions:
> 
> How should we go about spawning the binary given that we might want to
> have it run in a different mount namespace? There are at least two
> options:
> 
> 1) change the mount namespace first and then exec the binary (in effect
> run the binary with the given path from inside the container). This is
> possibly a security hole if an attacker can trick the kernel into
> running a different binary than intended by manipulating namespaces.
> 
> ...or...
> 
> 2) find and exec the binary and then change the namespaces afterward.
> This has some potential problems if the program does something like
> try to dlopen libraries after setns(). You could end up with a mismatch
> if the container holds a different set of binaries from the one in the
> root container.
> 
> -- 
> Jeff Layton <jlayton@primarydata.com>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html