[lxc-users] ID mapping blues (was: Does lxc-execute work with unprivileged containers?)

[Drake Wilson]

Patrick Toomey wrote:
> 1) Why is bash uid 0 in the container? Since I mapped the container
> uid 0-65536 to host uid 100000-165536 I would have expected my host
> uid (1000) to then map to the container 101000. And, then I would have
> expected the subordinate entry to map that to my_user. 
>
> 2) Why are my home directory files listed as being owned by nobody?
> I've seen that when playing with user namespaces (directly calling
> CLONE_NEWUSER) when you have no mapping configured in /proc/uid/uid_map.
> But, I checked the uid_map of the container process and it all seems to
> be setup correctly.

So, container 0 is host 100000, in that mapping.  So container 1000 is
host 101000, but host 1000 is not container 1000.  The files don't have
virtual ownerships; you're still accessing the same filesystem, and its
UID values are interpreted as host UIDs.  Host 1000 is unmapped in the
container, so it reads as nobody (the kernel still knows it's host 1000,
just from the in-namespace perspective there's no number to assign).

A user namespace gives you an entire set of "new" users starting from 0,
and 0/root in the namespace (technically, CAP_SETUID etc., but the UID
capability fixup means that's UID 0 unless you fiddle with caps specially)
has superuser powers over all the other IDs in the namespace.  They're not
"actually" new because they have to be one-to-one mapped to host UIDs so
that processes on the outside can introspect inward but not the other way
around, but as you can see they're usually a block not used elsewhere on
the host.

Does that at least explain the technical aspect?  (You need more than that
to do what you seemingly want to do, and it's much trickier than someone
looking from the user perspective might think, but I'm not quite awake
enough to formulate that part...)

   ---> Drake Wilson