> Von: lxc-users [mailto:[email protected]] Im 
> Auftrag
>
> Quoting Fiedler Roman ([email protected]):
> > 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).

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
lxc-users mailing list
[email protected]
http://lists.linuxcontainers.org/listinfo/lxc-users

Reply via email to