"J. Bruce Fields" <bfields@xxxxxxxxxxxx> writes: > On Wed, May 22, 2013 at 11:35:56AM -0700, Eric W. Biederman wrote: >> ebiederm@xxxxxxxxxxxx (Eric W. Biederman) writes: >> >> > I am missing a lot of context here and capturing the context of a >> > process at time time we mount the filesystem and reconstituing it in >> > call user mode helper seems like something we could do. > > So it's not enough just to ensure that the user namespace is set > correctly? (To the namespace of the mount process in the nfs case, or > of the process that starts nfsd in the nfsd case.) No. By just setting the user namespace, you gain the ability to create processes outside of your curremt rlimits, and cgroups, and pid namespace, etc. With the wrong set of namespaces you will talk to the wrong processes, or utilize the wrong resources. Outside of your current cgroup you gain the ability to use more resources than you were limited to. Having thought about it what I would propose is to fork a process from the context of the mounting process (or possibly from the context of the process that writes to the sysctl that sets the program to spawn) and have that process be a daemon that becomes responsible for spawning user mode helpers with context. Either that or whe need the user mode helper userspace infrastructure to become namespace aware and call setns. >> If we want to do something like this the only sane thing I can see is to >> have a per container version of kthread call it uthread. That the user >> mode helper code would use to launch a new process. >> >> Anything else and I expect we will be tearing our hair out for the rest >> of our lives with weird corner cases or unexpected semantics. > > Could you give examples of weird corner cases or unexpected semantics? I gave a couple and it is the classic problem with suid executables where a lot of unexpected things are inherited from the environment, and so things become a never ending race. We replaced daemonize in the kernel with just forking processes from kthreadd for this very reason. There was always something else that needed to be reset to make a process a proper kernel thread. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
