On Fri, Dec 14, 2012 at 03:10:30PM -0800, Eric W. Biederman wrote: > Neil Horman <nhorman@xxxxxxxxxxxxx> writes: > > > As its currently implemented, redirection of core dumps to a pipe reader should > > be executed such that the reader runs in the namespace of the crashing process, > > and it currently does not. This is the only sane way to deal with namespaces > > properly it seems to me, and this patch implements that functionality. > > I actually rather strongly disagree. > > While we have a global core dump pattern core dumps to a a pipe reader > should be executed such that the reader runs in the namespace of the > process that set the pattern. We can easily restrict that to the > initial namespaces to make the implementation simpler. > > If you want to play namespace games you can implement all of those in > user space once my tree merges for v3.8. > > I am really not a fan of the trigger process being able to control the > environment of a privileged process. It makes writing the privileged > process much trickier. > Why? What specific problem do you see with allowing a privlidged process to execute within a specific namespace, that doesn't also exist with having the pipe reader execute in the init namespace? Note I'm not saying that a poorly constructed pipe reader application doesn't have security problems if it doesn't validate the environment that its running in, but thats something that the pipe reader needs to be sure about. Note also, that if the token in core_pattern is set such that the core_pattern is namespace/root relative, that container needs to install the application relative its root as well (e.g. positive action still needs to be taken on the part of the container admin to make this work). For example, if you set core_pattern="||/usr/bin/foo" Then a process running in a chroot based at /sub/root/ still needs to install a file /sub/root/usr/bin/foo, or the core dump will fail. So its not like a container can just have a core reader execute without first making an administrative decision to do so. Neil _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
