On Wed, May 22, 2013 at 08:37:23PM -0700, Eric W. Biederman wrote: > "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. Got it, thanks for the explanation. --b. -- 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
