Package Details: bubblewrap-git v0.3.1.r6.g94147e2-1

Git Clone URL: https://aur.archlinux.org/bubblewrap-git.git (read-only, click to copy)
Package Base: bubblewrap-git
Description: Unprivileged sandboxing tool
Upstream URL: https://github.com/projectatomic/bubblewrap
Keywords: containers sandbox
Licenses: LGPL
Conflicts: bubblewrap
Provides: bubblewrap
Submitter: aperez
Maintainer: aperez
Last Packager: aperez
Votes: 4
Popularity: 0.000000
First Submitted: 2016-05-08 09:52 (UTC)
Last Updated: 2018-12-26 18:37 (UTC)

Required by (29)

Sources (1)

Latest Comments

aperez commented on 2017-01-10 23:07 (UTC)

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

mutantmonkey commented on 2017-01-08 01:10 (UTC) (edited on 2017-01-08 01:10 (UTC) by mutantmonkey)

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

JDCNS commented on 2016-12-25 18:16 (UTC)

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

aperez commented on 2016-12-08 13:44 (UTC)

@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.

yawning commented on 2016-12-06 05:23 (UTC)

They dropped support entirely for setcap. So the options are SUID root or nothing. https://github.com/projectatomic/bubblewrap/commit/aedd6136b7bc1165c164330d02e729e0a95d2487 Fun fun fun.

yawning commented on 2016-10-09 21:44 (UTC)

@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.

aperez commented on 2016-10-09 21:35 (UTC)

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

yawning commented on 2016-10-09 21:10 (UTC)

@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.

yawning commented on 2016-10-09 20:50 (UTC)

@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.

aperez commented on 2016-10-09 20:40 (UTC)

@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.

yawning commented on 2016-10-09 04:20 (UTC)

@aperez: TLDR: * USER_NS should use `--with-priv-mode=none`. * Non-USER_NS should use `--with-priv-mode=caps`. The reason why the package was broken on non-USER_NS kernels previously was because the capabilities granted in the `post_install()` were wrong/insufficient (because upstream changed the requirements), not because the binary needs to be SUID root. USER_NS removes the need for any elevated privileges as well. The upstream commit that broke the `post_install()` setcap directive was e0a07f4de70acb27d95bae69e27e42e5941e5873 , though as of your latest commit it's now correct.

aperez commented on 2016-09-22 09:01 (UTC)

@Pelzflorian: You're welcome! Let's hope USER_NS is enabled at some point in the default kernels, as more and more tools are likely to make use of it. I need it myself for Vagga, and adoption of things like Flatpak are probably going to push distributions to have the option enabled by default :-)

Pelzflorian commented on 2016-09-22 05:51 (UTC)

Thank you :) . Since this is an AUR package, build time checks seem OK.

aperez commented on 2016-09-22 02:18 (UTC)

@Pelzflorian: I have changed the PKGBUILD. If the running kernel does not have CONFIG_USER_NS enabled (user namespaces), then --with-priv-mode=setuid is passed to the configure script. Otherwise, if user namespaces are available use --with-priv-mode=caps.

Pelzflorian commented on 2016-09-19 05:14 (UTC)

Default Arch kernels do not support user namespaces (bug FS#36969), so on a default kernel, this should be configured with --with-priv-mode=setuid, in which case it also does not need the install file. If you want to keep using user namespaces (for non-default kernels), you or I could make a separate bubblewrap-setuid package for default kernels.