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@xxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
