mkdir -p /tmp/111 touch /tmp/111/1.txt touch /tmp/111/2.txt cd /tmp/111 tar cvf - . | xz -T 0 > /tmp/111.txz xz: Failed to enable the sandbox a . a ./1.txt a ./2.txt tar: Write error tar: Error exit delayed from previous errors. Exit 1
After 31857c44ecc18e720caf914fe6c1daced7dd5813 / MFV: xz 5.4.0
Created attachment 239758 [details] Patch to address the issue
Could you please test this patch? (You may have to do a clean buildworld in order to have it take effect) BTW. A quick glance at the base system suggests that WITHOUT_CAPSICUM is broken in many ways, for example, the headers are always installed regardless of the setting (otherwise the build of xz should fail). That's said, personally, I feel strongly that Capsicum should always be enabled and never disabled, because it has been proven over the last decade to give us more security margin for the base system, so perhaps we should just remove the option altogether and hard-wire it. I understand that my view may be somewhat aggressive and might be seen as very heavy-handed, and you might know some scenarios where this should continue to be an option, if so, could you please share?
Yes, this fix my issue. Thanks! PS: I feel safe without capsicum. Extra security can be obtained by using MAC.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=8f02c0d15669949bb3b5086800aaf11a65e4c871 commit 8f02c0d15669949bb3b5086800aaf11a65e4c871 Author: Xin LI <delphij@FreeBSD.org> AuthorDate: 2023-01-28 18:53:47 +0000 Commit: Xin LI <delphij@FreeBSD.org> CommitDate: 2023-01-28 18:53:47 +0000 Disable sandboxing when building with WITHOUT_CAPSICUM. PR: bin/269185 MFC after: 3 days lib/liblzma/config.h | 4 ++++ usr.bin/xz/Makefile | 6 +++++- 2 files changed, 9 insertions(+), 1 deletion(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=b38e81cff896eed0e38f611bd2c93229808a8ef9 commit b38e81cff896eed0e38f611bd2c93229808a8ef9 Author: Xin LI <delphij@FreeBSD.org> AuthorDate: 2023-01-28 18:53:47 +0000 Commit: Xin LI <delphij@FreeBSD.org> CommitDate: 2023-02-03 07:18:55 +0000 Disable sandboxing when building with WITHOUT_CAPSICUM. PR: bin/269185 (cherry picked from commit 8f02c0d15669949bb3b5086800aaf11a65e4c871) lib/liblzma/config.h | 4 ++++ usr.bin/xz/Makefile | 6 +++++- 2 files changed, 9 insertions(+), 1 deletion(-)
I came across this bug and it looks possibly related to something I'm experiencing. Trying to crosscompile with poudriere for 14.0-CURRENT arm64 on 14.0-CURRENT amd64 5245 --- archive.dir.tar.xz --- 5246 xz -c -5 < '.'/archive.dir.tar > archive.dir.tar.xz-t && mv archive.dir.tar.xz-t archive.dir.tar.xz 5247 xz: Failed to enable the sandbox 5248 *** [archive.dir.tar.xz] Error code 1 5249 5250 make[3]: stopped in /wrkdirs/usr/ports/devel/gettext-tools/work/gettext-0.21.1/gettext-tools/misc 5251 1 error 5252 5253 make[3]: stopped in /wrkdirs/usr/ports/devel/gettext-tools/work/gettext-0.21.1/gettext-tools/misc 5254 5255 make[2]: stopped in /wrkdirs/usr/ports/devel/gettext-tools/work/gettext-0.21.1/gettext-tools 5256 5257 make[1]: stopped in /wrkdirs/usr/ports/devel/gettext-tools/work/gettext-0.21.1/gettext-tools $ uname -a FreeBSD pyrogl.a9development.com 14.0-CURRENT FreeBSD 14.0-CURRENT main-n261155-6e9b4e3e0d4e GENERIC amd64 $ poudriere jail -l 14amd64 14.0-CURRENT 1400081 amd64 src=/usr/src 2023-02-28 23:55:36 /usr/local/poudriere/jails/14amd64 14arm64 14.0-CURRENT 1400081 arm64.aarch64 src=/usr/src 2023-03-01 18:56:36 /usr/local/poudriere/jails/14arm64 $ poudriere ports -l latest git+ssh 2023-03-01 12:20:31 /usr/local/poudriere/ports/latest usrports null 2021-08-09 14:05:55 /usr/ports $ git -C /usr/local/poudriere/ports/latest log -1 --oneline 0f57a0feb (HEAD -> main, origin/main, origin/HEAD) games/vcmi: the port had been updated to version 1.1.1
(In reply to Dan Kotowski from comment #7) Hi, it took me some time to set up a test environment and I was able to reproduce it. Looking deeper into the emulation code, it seems that qemu-bsd-user (in bsd-user/freebsd/os-proc.h) did not implement translation of capability system calls and will return ENOSYS. On the other hand, other system utilities would simply ignore failed cap_enter() calls when errno was ENOSYS, which seems to be a reasonable compromise: diff --git a/contrib/xz/src/xz/file_io.c b/contrib/xz/src/xz/file_io.c index a5841b370302..0af3a4885bd3 100644 --- a/contrib/xz/src/xz/file_io.c +++ b/contrib/xz/src/xz/file_io.c @@ -209,7 +209,7 @@ io_sandbox_enter(int src_fd) CAP_WRITE))) goto error; - if (cap_enter()) + if (cap_enter() && errno != ENOSYS) goto error; #elif defined(HAVE_PLEDGE) I'll send an email to xzutil's author and see if they would adopt a similar change.
I just ran into this attempting to use poudriere to build arm.armv7 packages (since I can't use pkg for those) on 13-Stable. The single-line patch did NOT resolve it; I put that in, committed it locally, updated the jail (the mod time on xz did change) and the package build still failed with inability to enable the sandbox in the same place within xz. I am currently disabling sandboxing in the jail entirely on xz and rebuilding it again; hopefully this isn't getting quietly overwritten somewhere (don't think so as the change was still in the source directory under the jail after it blew up the second time) but the one-line change does not, it appears, fix it for this environment.
Completely disabling sandboxing in the xz header file "private.h" permitted the build to continue. There's more to this than the one-liner would suggest, it appears, at least against 13-STABLE.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=c237c10a2346dec422233db05b2012afd45363fa commit c237c10a2346dec422233db05b2012afd45363fa Author: Xin LI <delphij@FreeBSD.org> AuthorDate: 2023-03-05 09:40:13 +0000 Commit: Xin LI <delphij@FreeBSD.org> CommitDate: 2023-03-05 09:40:13 +0000 xz: Improve compatibility with systems without capability mode support When the kernel is built without capability mode support, or when using an emulator like qemu-user-static that does not translate system calls, these calls will return a negative number and set the errno to ENOSYS. However, this error does not indicate a real programming or runtime error and is generally ignored by base system applications built with capability mode sandboxing. Match this behavior by making xz(1) to ignore ENOSYS errors when calling capability mode system calls too. PR: 269185 Reported by: Dan Kotowski MFC after: 2 days contrib/xz/src/xz/file_io.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=0cc2deb476bec103ad7c8dbeb650aa2937d6a0da commit 0cc2deb476bec103ad7c8dbeb650aa2937d6a0da Author: Xin LI <delphij@FreeBSD.org> AuthorDate: 2023-03-05 09:40:13 +0000 Commit: Xin LI <delphij@FreeBSD.org> CommitDate: 2023-03-07 06:55:41 +0000 xz: Improve compatibility with systems without capability mode support When the kernel is built without capability mode support, or when using an emulator like qemu-user-static that does not translate system calls, these calls will return a negative number and set the errno to ENOSYS. However, this error does not indicate a real programming or runtime error and is generally ignored by base system applications built with capability mode sandboxing. Match this behavior by making xz(1) to ignore ENOSYS errors when calling capability mode system calls too. PR: 269185 Reported by: Dan Kotowski (cherry picked from commit c237c10a2346dec422233db05b2012afd45363fa) contrib/xz/src/xz/file_io.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
A commit in branch stable/12 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=2e12642a65957e7ab518699e1f8a9a5aa95ea45f commit 2e12642a65957e7ab518699e1f8a9a5aa95ea45f Author: Xin LI <delphij@FreeBSD.org> AuthorDate: 2023-03-05 09:40:13 +0000 Commit: Xin LI <delphij@FreeBSD.org> CommitDate: 2023-03-07 06:56:18 +0000 xz: Improve compatibility with systems without capability mode support When the kernel is built without capability mode support, or when using an emulator like qemu-user-static that does not translate system calls, these calls will return a negative number and set the errno to ENOSYS. However, this error does not indicate a real programming or runtime error and is generally ignored by base system applications built with capability mode sandboxing. Match this behavior by making xz(1) to ignore ENOSYS errors when calling capability mode system calls too. PR: 269185 Reported by: Dan Kotowski (cherry picked from commit c237c10a2346dec422233db05b2012afd45363fa) contrib/xz/src/xz/file_io.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
A commit in branch releng/13.2 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=139825753995ca25a1d40df9f067a1fa4e847d44 commit 139825753995ca25a1d40df9f067a1fa4e847d44 Author: Xin LI <delphij@FreeBSD.org> AuthorDate: 2023-03-05 09:40:13 +0000 Commit: Xin LI <delphij@FreeBSD.org> CommitDate: 2023-03-08 03:51:36 +0000 xz: Improve compatibility with systems without capability mode support When the kernel is built without capability mode support, or when using an emulator like qemu-user-static that does not translate system calls, these calls will return a negative number and set the errno to ENOSYS. However, this error does not indicate a real programming or runtime error and is generally ignored by base system applications built with capability mode sandboxing. Match this behavior by making xz(1) to ignore ENOSYS errors when calling capability mode system calls too. PR: 269185 Reported by: Dan Kotowski Approved by: re (cperciva) (cherry picked from commit c237c10a2346dec422233db05b2012afd45363fa) (cherry picked from commit 0cc2deb476bec103ad7c8dbeb650aa2937d6a0da) contrib/xz/src/xz/file_io.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
(I'll give qemu-bsd-user a shot too, but closing this one as closed as the historical behavior is restored).