Re: [PATCH 11/11][v15]: Document sys_eclone

["Serge E. Hallyn" <serge.hallyn-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>]

Quoting Albert Cahalan (acahalan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org):
> On Mon, Jul 5, 2010 at 12:18 AM, Oren Laadan <orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org> 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