On Thu, Jan 08, 2015 at 09:25:07PM +0100, Tom Gundersen wrote:
> On Thu, Jan 8, 2015 at 8:59 PM, Stéphane Graber <stgra...@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 <stgra...@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,
>
> TomHmm, indeed, looking at the kernel code, mknod and mount are restricted even if the container's uid 0 is mapped to real uid 0. As far as I know there's no obvious way to detect this case (well, short of trying a bunch of restricted syscalls). The only way I'm aware of is by comparing the target of /proc/self/ns/user to that of /proc/<real host pid 1>/ns/user which is doable at the host level but isn't once you are in a container with your own pid namespace (which since we're talking about pid 1 systemd there can probably be assumed). > > [0]: <lwn.net/Articles/539940/> > [1]: > > [root@tomegun-x240 userns]# ./userns_child_exec -U -M '0 0 4294967295' > -G '0 0 4294967295' bash > [root@tomegun-x240 userns]# mknod null b 1 3 > mknod: ‘null’: Operation not permitted > [root@tomegun-x240 userns]# mount -t tmpfs none test/ > mount: permission denied > [root@tomegun-x240 userns]# exit > exit > [root@tomegun-x240 userns]# mknod null b 1 3 > [root@tomegun-x240 userns]# mount -t tmpfs none test/ -- Stéphane Graber Ubuntu developer http://www.ubuntu.com
signature.asc
Description: Digital signature
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
