From the systemd test suite: floppym@naomi systemd-254-rc2-abi_x86_32.x86 % sudo -u portage sandbox ./test-fileio /* test_test_fdopen_independent */ * ACCESS DENIED: open_wr: /proc/self/fd/3 Assertion 'fdopen_independent(fd, "r+e", &f) >= 0' failed at src/test/test-fileio.c:1118, function test_test_fdopen_independent(). Aborting. Sandboxed process killed by signal: Aborted * ----------------------- SANDBOX ACCESS VIOLATION SUMMARY ----------------------- * LOG FILE: "/var/log/sandbox/sandbox-991957.log" * VERSION 1.0 FORMAT: F - Function called FORMAT: S - Access Status FORMAT: P - Path as passed to function FORMAT: A - Absolute Path (not canonical) FORMAT: R - Canonical Path FORMAT: C - Command Line F: open_wr S: deny P: /proc/self/fd/3 A: /proc/self/fd/3 R: /memfd:fdopen_independent (deleted) C: ./test-fileio * --------------------------------------------------------------------------------
julia-1.8.5-r1 fails to build with sanbox-2.37. The offending ops are fchmod and fchown on something similar (/proc/self/fd/N) downgrading to 2.32 (no ~amd64 on this system) fixes the build.
(In reply to foufou33 from comment #1) > julia-1.8.5-r1 fails to build with sanbox-2.37. The offending ops are fchmod > and fchown on something similar (/proc/self/fd/N) > downgrading to 2.32 (no ~amd64 on this system) fixes the build. Please share the full logs.
Created attachment 866037 [details] julia's sandbox.log
Created attachment 866038 [details] julia's build log
It's the same issue. sandbox-2.32 does not check fchmod. sandbox-2.37 does.
This is the code for that test: assert_se(fdopen_independent(fd, "r+e", &f) >= 0); zero(buf); assert_se(fread(buf, 1, sizeof(buf), f) == strlen(TEST_TEXT)); assert_se(streq(buf, TEST_TEXT)); assert_se((fcntl(fileno(f), F_GETFL) & O_ACCMODE) == O_RDWR); assert_se(FLAGS_SET(fcntl(fileno(f), F_GETFD), FD_CLOEXEC)); f = safe_fclose(f); It's not actually writing anything, it's only checking that the "r+e" mode results in O_RDWR (earlier tests confirm the contents of the file).
I think the leading slash in "/memfd:" is causing sandbox to think this is an actual path rather than an abstract object. Other objects like sockets and pipes show up as "socket:..." and "pipe:..." in /proc/self/fd, and sandbox just ignores them. I really wish the kernel devs had maintained that convention for memfd, but I guess we will just need to work around it by looking for "/memfd:" and skipping the access check.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/sandbox.git/commit/?id=27232d52fee4abecd5f709acc616fa1296e0464f commit 27232d52fee4abecd5f709acc616fa1296e0464f Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2023-07-31 15:39:40 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2023-07-31 15:42:59 +0000 libsandbox: always permit access to '/memfd:' For memfd objects, the kernel populates the target for symlinks under /proc/$PID/fd as "/memfd:name". Said target does not actually exist. It is unfortunate that the kernel includes the leading slash, but we will just have to work around it. Bug: https://bugs.gentoo.org/910561 Signed-off-by: Mike Gilbert <floppym@gentoo.org> libsandbox/libsandbox.c | 6 ++++++ 1 file changed, 6 insertions(+)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=761c8d19f1549cd137d2b0a0cbcb12f569dfba5e commit 761c8d19f1549cd137d2b0a0cbcb12f569dfba5e Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2023-08-06 00:50:57 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2023-08-06 00:51:49 +0000 sys-apps/sandbox: add 2.38 Closes: https://bugs.gentoo.org/906234 Closes: https://bugs.gentoo.org/910273 Closes: https://bugs.gentoo.org/910561 Signed-off-by: Mike Gilbert <floppym@gentoo.org> sys-apps/sandbox/Manifest | 1 + sys-apps/sandbox/sandbox-2.38.ebuild | 64 ++++++++++++++++++++++++++++++++++++ 2 files changed, 65 insertions(+)
*** Bug 916468 has been marked as a duplicate of this bug. ***
*** Bug 911162 has been marked as a duplicate of this bug. ***
