[Pkg-shadow-devel] [test] newuidmap/newgidmap

[Serge Hallyn]

Quoting Philippe Grégoire (gregoirep at hotmail.com):
> On 2014-06-03 18:52:57 (+0000), Serge Hallyn wrote:
> > Quoting Philippe Grégoire (gregoirep at hotmail.com):
> > > 
> > > TLDR; no easy solution. Either the /etc/subuid is in the kernel and we remove
> > > the file. Or newuidmap reflects the kernel, and they must be kept in sync.
> > 
> > Allowed subuids represent policy which as much as possible belongs in
> > userspace, not the kernel.
> > 
> > > I had to play with it because lxc is broken on Debian, and Ubuntu. Quickly, I
> > > can create a container as a unprivileged user but running it produces:
> > > 
> > >   'Error creating container whatever'
> > 
> > serge at sergelap:~$ lxc-usernsexec
> > # id
> > uid=0(root) gid=0(root) groups=0(root)
> > 
> Hardly impressing...

Wasn't trying to impress, but to show that lxc-usernsexec is the tool for simply
using uid mappings.  You can create containers without cgroups, but the default
templates very much do need cgroups (at least the devices cgroup), since most
people are not yet using user namespaces (and many cannot and never will be able
to)

> > > which is, quite frankly, purely unsatisfying. What am I expected to do with that
> > > error message? What am I suppose to investigate? Also, why would cgroups be
> > > mandatory? etc. But that is another topic; and I am no longer interested in lxc
> > > (version 1.x? -- please...).
> > ...
> 
> Better! On sid ...
> 
> pg at p01:~$ sudo /bin/echo 1 > /proc/sys/kernel/unprivileged_userns_clone
> pg at p01:~$ grep pg /etc/sub*id
> pg:200000:65536
> pg:200000:65536
> pg at p01:~$ mkdir ~/.config/lxc
> pg at p01:~$ printf "lxc.id_map = u 0 200000 65536\nlxc.id_map = g 0 200000 65536\n" > ~/.config/lxc/default.conf
> pg at p01:~$ lxc-create -l DEBUG -o lxc.log -n whatever
> Error creating container whatever
> pg at p01:~$ cat lxc.log
>      lxc-create 1401822796.086 INFO     lxc_utils - XDG_RUNTIME_DIR isn't set in the environment.
>      lxc-create 1401822796.086 WARN     lxc_log - lxc_log_init called with log already initialized
>      lxc-create 1401822796.086 INFO     lxc_confile - read uid map: type u nsid 0 hostid 200000 range 65536
>      lxc-create 1401822796.087 INFO     lxc_confile - read uid map: type g nsid 0 hostid 200000 range 65536
>      lxc-create 1401822796.087 ERROR    lxc_create_ui - Error creating container whatever

Right, so if all you wanted was a uid mapping, you could just

serge at sergeh1:~$ grep serge /etc/subuid
serge:100000:200001
serge at sergeh1:~$ lxc-usernsexec -m b:0:100000:10000 -- /bin/bash
root at sergeh1:~# id
uid=0(root) gid=0(root) groups=0(root)
root at sergeh1:~# lxc-unshare -s "MOUNT|PID" /bin/sh
lxc: call to cgmanager_move_pid_abs_sync(hugetlb) failed: invalid request
# mount -t proc proc /proc
# cat /proc/self/uid_map
         0     100000      10000

Anyway part of me wants to say "this isn't the right list for this", but
on the other hand, the question of the appropriate place to configure,
administer, and use user namespaces is, and the first part of this is
where this came from.

So back to the original issue:  it seems clear to me that the subuids
allowed for unprivileged users do belong where they are, and not in the
kernel.  The other remaining question is whether newuidmap should, if
a requested subuid is not listed in /etc/subuid, check for the caller's
privilege over the requested subuid.  That is actually a thorny issue,
since the caller could have had CAP_SETUID in his pE, before he called
newuidmap which recalculated his caps.  Conversely, the caller could
have been uid 0 but with no capabilities (in
SECBIT_NOROOT|SECBIT_NO_SETUID_FIXUP, which would have required
newuidmap to be installed with filecaps, but that's easy enough to
do).

So I'm actually talking myself into agreeing with Eric that we should
not have an exception for root.

-serge