Package Details: bubblewrap-suid-git 0.11.0.r2.gd6180f2-1

Git Clone URL: https://aur.archlinux.org/bubblewrap-git.git (read-only, click to copy)
Package Base: bubblewrap-git
Description: Low-level unprivileged sandboxing tool (setuid variant)
Upstream URL: https://github.com/containers/bubblewrap
Licenses: LGPL-2.0-or-later
Conflicts: bubblewrap-suid
Provides: bubblewrap-suid
Submitter: aperez
Maintainer: Chocobo1
Last Packager: Chocobo1
Votes: 4
Popularity: 0.000000
First Submitted: 2016-05-08 09:52 (UTC)
Last Updated: 2025-08-08 09:14 (UTC)

Required by (2)

  • rua (requires bubblewrap-suid) (optional)
  • rua-git (requires bubblewrap-suid) (optional)

Sources (1)

Latest Comments

1 2 Next › Last »

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.

1 2 Next › Last »