[pkg-lxc-devel] Bug#847491: Bug#847491: lxc: please put the lxc-unshare and lxc-usernsexec tools into their own binary package

[Johannes Schauer]

On Thu, 8 Dec 2016 20:39:29 -0600 "Serge E. Hallyn" <serge at hallyn.com> wrote:
> > with this bug I want to propose a patch against the lxc source package
> > which splits out the lxc-unshare and lxc-usernsexec utilities into their
> > own binary package. It follows the rationale.
> > 
> > The lxc package currently contains the two tools lxc-unshare and
> > lxc-usernsexec. The only thing that these tools have in common with the
> > other lxc tools is that they are prefixed with "lxc-". They are not
> > manipulating any lxc containers. Still, these two binaries provide some
> > very powerful facilities which are so far unique in Debian: they allow
> > to easily enter a new user namespace and unshare several other
> > namespaces from within it. There exists the "unshare" utility from the
> > util-linux binary package, but that one doesn't offer all the
> > functionality that the lxc-unshare and lxc-usernsexec tools offer. One
> > important limitation of the unshare tool is, that it doesn't yet allow
> > mounting /proc which is a crucial drawback. So even though the
> > lxc-unshare tool is described as "mainly provided for testing purposes"
> > in its man page, it is so far the only tool in Debian which allows
> > easily setting up fully-fledged (including /proc) unprivileged chroots
> > from within shell scripts.
> > 
> > One problem right now is, that to acquire the lxc-unshare and
> > lxc-usernsexec utilities, one has to install the full lxc package. Due
> > to its dependencies, that can mean up to 95.5 MB of additional disk
> > space being required for 74 new packages. Even when installing with
> > --no-install-recommends, still 33.2 MB of additional disk space will be
> > used for 22 new packages. It would make things much more light-weight if
> > the two tools would live in their own binary package because that would
> > limit the amount of additionally required disk space to 1172 kB for just
> > 5 more packages on top of a minimal installation.
> > 
> > The attached patch adds the lxc-userns-tools binary package. The name is
> > obviously free to be changed to something else. I also let the lxc
> > package depend on the lxc-userns-tools package. That way, existing users
> > of the lxc package will not see a difference in provided functionality.
> > The main overhead and complication that this patch adds are much longer
> > *.install files but since you are also using "dh_install --fail-missing"
> > there is no way that the list in lxc.install could become outdated in
> > the future without you noticing via a build failure.
> > 
> > What do you think?
> Note that lxc-unshare is basically obsoleted by 'unshare' in util-linux.
> lxc-usernsexec is, last I checked, still worthwhile, though patching unshare
> to have similar uidmap capabilities might be the best way forward.  (In
> particular, user-specifiable uid maps, and ability to use the first mapping
> found in /etc/subuid)

You are right, the unshare utility from util-linux works perfectly for my
use-case. Since lxc-usernsexec is still part of the lxc package, I wrote my own
utility that emulates its functionality in Perl. In case anybody is interested,
I attached the script.

It will be part of the next sbuild release.

This also means, that I'll no longer be using lxc-usernsexec and you can feel
free to close this bug.

Thanks!

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: user-unshare
Type: text/x-perl
Size: 12870 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-lxc-devel/attachments/20180610/6671096c/attachment.pl>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-lxc-devel/attachments/20180610/6671096c/attachment.sig>