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@xxxxxxxxxxxxxxx> > -- > 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 -- 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
