[systemd-devel] [PATCH 1/2] Add detect_userns to detect uid/gid shifts

[Tom Gundersen]

On Thu, Jan 8, 2015 at 8:59 PM, Stéphane Graber <stgraber at ubuntu.com> wrote:
> On Thu, Jan 08, 2015 at 08:43:12PM +0100, Tom Gundersen wrote:
>> On Thu, Jan 8, 2015 at 8:27 PM, Stéphane Graber <stgraber at ubuntu.com> wrote:
>> > +        /* If both uid_map and gid_map don't exist or if they both match
>> > +         * the full uid/gid range, then we're not inside a user namespace */
>>
>> Hm, this is not necessarily true is it? In my naive test, it works
>> just fine to set up a usernamespace with the identity mapping.
>> Moreover, this appears to be functionally different from the initial
>> user namespaces (somewhat counter-intuitively I might add), so
>> treating the identity mapping as 'no user namespace' is probably not
>> the right thing to do.
>>
>> Is there no better way to test for this?
>
> I'm not sure I understand what you mean there.
>
> When you unshare CLONE_NEWUSER, your uid_map and gid_map are empty. You
> can then write a map using your own uid and gid or use a privileged
> helper to write a larger map.
>
> The only case where you could be in a separate user namespace and still
> have the same map as the host is if you had a privileged helper write
> the whole host uid and gid map to your process' uid_map and gid_map, in
> which case, your process' uid 0 is mapped to the host uid 0

Yeah, I'm looking at privileged user namespaces, so you are setting
them up as root (which I understand is different from your usecase
where you want to do this as a regular user).

To be clear, I used Michael Kerrisk's test tool [0] like this (as root):

# ./userns_child_exec -U -M '0 0 4294967295' -G '0 0 4294967295' bash

> and while
> you are technically in a different namespace than the host, your
> accesses are identical and so it's not unreasonable to have
> detect_userns report this as the host namespace.

It appears to me that this ("your accesses are identical") is not true
though. At least I found mknod(8) and mount(8) to work on the host,
but not in the identity-mapped user namespace [1]. Had it been true, I
would agree with you that we should just treat this the same as not
being in a user namespace, but as this is not the case (or I'm doing
something wrong in my test) we may want to be careful here.

Obviously, the identity-mapped user namespace does not sound at all
useful to me, so maybe we can ignore it (if there really is no other
way), but we should document that at least.

Cheers,

Tom

[0]: <lwn.net/Articles/539940/>
[1]:

[root at tomegun-x240 userns]# ./userns_child_exec -U -M '0 0 4294967295'
-G '0 0 4294967295' bash
[root at tomegun-x240 userns]# mknod null b 1 3
mknod: ‘null’: Operation not permitted
[root at tomegun-x240 userns]# mount -t tmpfs none test/
mount: permission denied
[root at tomegun-x240 userns]# exit
exit
[root at tomegun-x240 userns]# mknod null b 1 3
[root at tomegun-x240 userns]# mount -t tmpfs none test/