Re: Could you write some CLONE_NEWUSER?

["Serge E. Hallyn" <serue@us.ibm.com>]

Quoting Bryan Donlan (bdonlan@gmail.com):
> This is something more of a general question than one about this
> manpage, but how will files owned by user namespaces be represented on
> the underlying filesystem? Since (C, 501) will be meaningless after a
> reboot at the latest, it makes little sense to persist them...

Yeah that's a very interesting question.  Clearly persistant names for
the user namespaces are needed.  Eric very much wanted to avoid having
the user namespaces be explicitly named, so we pursued the path of
having the filesystem handle the naming.  So in my last patchset,
a mount option could register the mounter's user namespace name.
There would be a system-wide policy saying for instance that (B,500)
user namespaces owned by can register themselves at C.

(end of discussion arising from that patchset is here: )
https://lists.linux-foundation.org/pipermail/containers/2008-August/012793.html

In the simplest case of no fs support for user namespaces, the mount
will be 'owned' by the userns which mounted it (no persistant name
needed for that).  Users who are in a different namespace will only get
the 'user other' permission to the file/dir, and may not create files
there (since we wouldn't know which userid to place on it).

Then the fs can support user namespaces - however it wants.  It could
just store (B, 500),(C, 501) in an xattr.  Or it could just store the
userid and userns name of the lowest user (I.e. C and 0), and count on
knowning that (B, 500) owns user namespace C.  We do want to provide
generic helpers in lib/fsuserns.c which any fs could use.

But yes, picking a meaningful persistant name for a user namespace
is an issue.

-serge