[lxc-users] lxc-usernsexec not working any more (differently) in lxc2 when invoked as root user: better solutions?

[Fiedler Roman]

> Von: lxc-users [mailto:lxc-users-bounces at lists.linuxcontainers.org] Im 
> Auftrag
>
> Quoting Fiedler Roman (Roman.Fiedler at ait.ac.at):
> > Hello List,
> >
> > With LXC1 on Trusty following sequence was used to fill an unprivileged
> > container as root, where only configuration exists but no content. With
> LXC2
> > on Xenial, this results in an error:
> >
> > cd -- /var/lib/lxc/test/rootfs
> > lxc-usernsexec -m u:0:296608:65536 -m g:0:296608:65536 -- tar
>
> Do you have /etc/subuid and /etc/subgid entries for root including
> this range?
>
> > --numeric-owner --exclude=./dev -xjf
> > [somepath]/ubuntuxenial1604-i386.tar.bz2
> > newuidmap: uid range [0-65536) -> [296608-362144) not allowed
> > error mapping child
> >
> > Deleting the file "/usr/bin/newuidmap" fixes the problem, but I guess that
> > is not the best idea :-)
>
> Right, that sounds like your lxc1 is so old that it defaults to not using
> newuidmap when you're root, which was changed years ago to default to
> using
> newuidmap.  (By requiring uid allocations for the root user, we prevent
> accidental  clashes with subuid allocations for non-root users )

But the uid-map supplied is correct for a given non-root user, just newuidmap 
assumes for some unknown reason, that there are clashes. When this procedure 
is prevented, because it is too risky, how to perform it correctly (without 
workarounds or downgrading to very old version)?

Is the procedure depicted below the recommended, correct way to do it?

> > Following command works also ...
> >
> > bzip2 -cd < [somepath]/ubuntuxenial1604-i386.tar.bz2 | PATH=""
> > /usr/bin/lxc-usernsexec -m u:0:296608:65536 -m g:0:296608:65536 --
> /bin/tar
> > --numeric-owner --exclude=./dev -x
> >
> > ... but maybe there is a smarter way to avoid that problem? Is there a way
> > to use "lxc-create" in a way, that it does not touch any file-system
> > property (mode/owner/xattrs) nor any file content EXCEPT extracting a tar
> to
> > the prepared directory? Using PATH does not seem very sensible as it could
> > provoke regressions as it relies on undocumented internal function of "
> > lxc-usernsexec".
> >
> > Kind regards,
> > Roman
> >
> > PS: after UID-mapping the procedure should not attempt a chdir: when
> mapped
> > and not already inside, it will have no means to reach the container 
> > rootfs
> > location any more (as no other non-host-root process has).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6344 bytes
Desc: not available
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20160627/d462b76f/attachment.bin>