Quoting Albert Cahalan (acahalan@xxxxxxxxx): > On Mon, Jul 5, 2010 at 12:18 AM, Oren Laadan <orenl@xxxxxxxxxxxxxxx> wrote: > > Finally, there have been objections before to allow pid-selection > > by non-privileged process. > > Eh, I dearly hope that privileged processes are generally not > even addressable (never mind creatable or accessable) from > inside anything other than the top-level pid namespace. If a privileged task was created in the top-level pid namespace, then it is not addressable from inside a descendent pid namespace. > Well, at least nothing should get more privilege than PID 1. > This would include having UID values that PID 1 can switch > to and having capability sets that PID 1 can switch to, and > any other (SE Linux, AppArmor, etc.) things too. IIUC the spirit of what you say here is what is intended by the completion of the user namespaces. They'll ensure that things like setuid-root and file capabilities limit privilege to resources owned by the task which created the namespace. That's why unprivileged pid ns unsharing won't be considered until user namespaces are completed. > Restarting a privileged process with a less privileged PID 1 > should result in privilege loss, and ought to require some sort of > "--force" option to ensure the person accepts possible breakage. Interesting point. Do we allow ptrace of a container init? -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
