Arch Linux User Repository

@mutantmonkey @JDCNS: Good catch! I have added “docbook-xsl” to the build dependencies, thanks.

Please add docbook-xsl to makedepends. This missing dependency is the reason for that docbook.xsl error that @JDCNS is experiencing.

I'm not sure why this isn't building for me. It appears it cannot download docbook.xsl, but when I right-click on the link in the terminal and choose "Open Link", it does open a page and downloads it. So, looking at the line (and being unfamiliar with xsltproc), is it really bwrap.xml causing the error?

Make outputs:

xsltproc --nonet --stringparam man.output.quietly 1 --stringparam funcsynopsis.style ansi --stringparam man.th.extra1.suppress 1 --stringparam man.authors.section.enabled 0 --stringparam man.copyright.section.enabled 0 http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl bwrap.xml
I/O error : Attempt to load network entity http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
warning: failed to load external entity "http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl"
cannot parse http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl

@yawning: I think the best then is to always install the binary setuid *and* notify users in the postinst() function that they may remove the setuid bit if they have a kernel with USER_NS. I'll push a commit soon with that.

They dropped support entirely for setcap. So the options are SUID root or nothing.

https://github.com/projectatomic/bubblewrap/commit/aedd6136b7bc1165c164330d02e729e0a95d2487

Fun fun fun.

@aperez: The binary doesn't need to be SUID root if the install hook is getting called, since the setcap call grants all the required privileges.

https://aur.archlinux.org/cgit/aur.git/commit/?h=bubblewrap-git&id=21c542a05aa20b480995aeb29598a509c2dcc6c3

Along with always using the install hook should basically just work on most systems (grsec kernels have `USER_NS` but still require capabilities because the grsec patch disables the unprivileged component of it, normal `USER_NS` kernels should be fine though).

Sorry for the back and forth.

@yawning: Ouch, good catch! Updated again, and now the .install script is always used, as intended.

@aperez: Ah that's why.

https://aur.archlinux.org/cgit/aur.git/commit/PKGBUILD?h=bubblewrap-git&id=21c542a05aa20b480995aeb29598a509c2dcc6c3

install='bubblewrap.install' needs to be the default behavior (applied when capabilities are desired, since that's what calls setcap on the binary). Right now, it's being applied when, you probably don't need any capabilites at all.

@aperez: As far as I can tell, the post install hook isn't getting run correctly with your previous commit:

% sudo pacman -U bubblewrap-git-0.1.2.r1.g169db04-1-x86_64.pkg.tar.xz
% ls -l /usr/bin/bwrap
-rwxr-xr-x 1 root root 39664 Oct 9 20:35 /usr/bin/bwrap
% getcap /usr/bin/bwrap <- That's odd. The package manager should have setcaped it on install....
% sudo setcap cap_sys_admin,cap_net_admin,cap_sys_chroot,cap_setuid,cap_setgid+ep /usr/bin/bwrap
% getcap /usr/bin/bwrap
/usr/bin/bwrap = cap_setgid,cap_setuid,cap_net_admin,cap_sys_chroot,cap_sys_admin+ep <- Expected output
% bwrap --ro-bind / / bash
$

You can try this yourself by copying the bwrap binary somewhere, removing the SUID flag, and setcap-ing the copy.

@yawning: Thanks for the tip, but it seems that having capabilities is not enough for Non-USER_NS systems. I have just tried locally and I get:

% bwrap --ro-bind / / bash
Creating new namespace failed, likely because the kernel does not support user namespaces. bwrap must be installed setuid on such systems.

The correct way still seems to be:

* USER_NS: --with-priv-mode=caps
* Non-USER_NS: --with-priv-mode=setuid

The latest version I have just pushed should handle this correctly, with some extra added bits in the .install file.