| Summary: | sys-apps/coreutils-8.3{1,2}-r1[static]: sandbox violation on /usr/tmp/ | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Kirill Chibisov <contact> |
| Component: | Current packages | Assignee: | Sandbox Maintainers <sandbox> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | base-system, sam |
| Priority: | Normal | Keywords: | PATCH |
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=674300 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
build.log
emerge --info output 0001-etc-sandbox.conf-allow-usr-tmp-for-write.patch |
||
Created attachment 654734 [details]
build.log
Created attachment 654736 [details]
emerge --info output
I had two symptoms: 1) freetype hanging on configure --help 2) coreutils dying with sandbox failures on emerge, like "ACCESS DENIED: MKDIR: /usr/tmp/cf136." A user (jjakob) on IRC mentioned similar issues after playing with USE="static static-libs" on some packages. For me, this was happening in my x86 tatt chroot where USE flags get flipped often. Environment was clear of /usr/tmp etc. Turns out coreutils had static enabled. Re-emerging coreutils (with sandbox temporarily disabled) resolved both 1) and 2). Perhaps masking USE=static could be a good idea (I would guess consumers should use busybox anyway for such needs) but there may be uses I don't know about. I saw other forum posts about this: https://forums.gentoo.org/viewtopic-t-1090738-start-0.html https://forums.gentoo.org/viewtopic-t-1100356-start-0.html TL;DR: FEATURES="-sandbox -usersandbox" USE="-static" emerge -av1 sys-apps/coreutils (but then make sure static is not being enabled anywhere on coreutils; better yet, don't enable it on anything.) floppym gave some insight: [18:45:52] <@floppym> sys-apps/sandbox uses a different code path when dealing with static binaries, so it is likely there is some bug there. [18:46:31] <@floppym> It can't use LD_PRELOAD to inject itself for static binaries, so it has to resort to using ptrace via the kernel. Passing this over to the sandbox maintainer to take a look. This has nothing to do with static. I have seen this error multiple times by myself. I still don't know exactly what's going on. In my cases it helped to re-created /usr/tmp symlink. I was using XFS for /var/tmp. Current suspicion is that there is/was a problem with XFS 64bit inodes (Patrick mentioned a similar problem). Before I re-created that symlink I mounted tmpfs on top which also worked. (In reply to Thomas Deutschmann from comment #6) > This has nothing to do with static. > > I have seen this error multiple times by myself. I still don't know exactly > what's going on. In my cases it helped to re-created /usr/tmp symlink. > > I was using XFS for /var/tmp. > > Current suspicion is that there is/was a problem with XFS 64bit inodes > (Patrick mentioned a similar problem). Before I re-created that symlink I > mounted tmpfs on top which also worked. My /var and /usr are ext4 (inside /), no separate mounts. I had the exact same sandbox violations (access denied to /usr/tmp/cf129) while re-emerging coreutils and patch, and a hang on freetype in exactly the same place Sam James had it. My backstory is, I set USE=static and re-emerged @world, then removed USE=static and re-emerged @world again. coreutils and patch failed to re-emerge. Using Sam James's workaround to re-emerge coreutils with sandbox disabled fixed all issues. I digged into patch's configure script to see what failed and found the offending mkdir in the "checking for long file names" part. >My /var and /usr are ext4 (inside /), no separate mounts. I had the exact same sandbox violations (access denied to /usr/tmp/cf129) while re-emerging coreutils and patch, and a hang on freetype in exactly the same place Sam James had it. >My backstory is, I set USE=static and re-emerged @world, then removed USE=static and re-emerged @world again. coreutils and patch failed to re-emerge. Using Sam James's workaround to re-emerge coreutils with sandbox disabled fixed all issues. I have similar setup with ext4(only home and / are separate partitions), and I also did emerge with +static and then removed it. No XFS or something like that at all on my side. For me to repro it only requires reemerging coreutils without static with coreutils that have static already. OK, we had a chat about this in #gentoo-dev: To reproduce this, first you have to emerge coreutils[static]. Once you have coreutils[static] merged on your system, i.e. you are now using static coreutils, you will hit this problem. And you won't just hit this with coreutils alone - basically any binary accessing files which is build statically can cause this. That's because of sandbox which cannot do its job on static binaries. There is nothing we can do here. We will probably close this issue as invalid or as duplicate (once we found the bug where sandbox maintainer explained that). And in long term, any Gentoo package will lose its static USE flag. >And you won't just hit this with coreutils alone - basically any binary accessing files which is build statically can cause this. That's because of sandbox which cannot do its job on static binaries. Yeah, that makes sense, but it depends how you do sandboxing here. >There is nothing we can do here. We will probably close this issue as invalid or as duplicate (once we found the bug where sandbox maintainer explained that). I'm not sure, but if something really can't be done, you can at least warn users that static build will fail for some specific reason. Also, I'm not entirely sure that you can't isolate by using chroot(moving required things into build env) for build, but I'm not familiar how sandboxing works on gentoo. >And in long term, any Gentoo package will lose its static USE flag. Well, static could actually work, knowing that there's musl support in gentoo, I agree that it's kind of pointless with glibc, but with musl they work fine, and some users prefer static builds over dynamic for security reasons (yes, you can shout that dynamic is more secure, but it's a bit heated topic imho). Just to clarify, since I think there could a bit of confusion wrt my last comment (on #gentoo-dev). I don't care what you'll do with coreutils's static use flag, you can remove static from it entirely, or if you decide to keep it, you should inform that it'll break sandbox. Exposing to user something that is obviously broken, and not telling the user that it'll break things is a bug imho. From my side, I've just reported sandbox violation bug that I've noticed while testing something with 'static', nothing more, I don't use static in general. However I don't see a point from removing static from all the packages in gentoo, other than 'sandbox can't work with them, so we just remove the thing entirely'. Like qemu (not entirely sure about that one)/busybox, seem like a valid use case, no? Maybe some other utils could benefit from static in some strange cases... (In reply to Thomas Deutschmann from comment #9) > OK, we had a chat about this in #gentoo-dev: > > To reproduce this, first you have to emerge coreutils[static]. Once you have > coreutils[static] merged on your system, i.e. you are now using static > coreutils, you will hit this problem. > > And you won't just hit this with coreutils alone - basically any binary > accessing files which is build statically can cause this. That's because of > sandbox which cannot do its job on static binaries. sandbox does handle static binaries. If it did not you would not see an access violation. It would just not detect it. There is something different between mkdir syscall precheck and library override precheck. The trigger is /usr/tmp/ being a symlink. Non-symlink absolute paths seem to work fine. Library wrapper resolves into /var/tmp/ and passes directory whitelist. Syscall wrapper fails the resolution. /usr/tmp is not in a read/write whitelist. Created attachment 668006 [details, diff]
0001-etc-sandbox.conf-allow-usr-tmp-for-write.patch
0001-etc-sandbox.conf-allow-usr-tmp-for-write.patch allows /usr/tmp for write.
Alternatively we can declare coreutils buggy as it tries to access a directory for write not specified by PMS, which is: https://dev.gentoo.org/~ulm/pms/head/pms.html """ [...] as well as write access to the temporary directories specified by the T, TMPDIR and HOME environment variables. [...] Most functions must assume only that they have additional write access to the package’s working directory (the WORKDIR environment variable) [...] """ (even though it's a symlink to one of these paths) The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/sandbox.git/commit/?id=001a95fb06aea725642397db09584a05c39246c9 commit 001a95fb06aea725642397db09584a05c39246c9 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2020-10-23 07:07:55 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2021-03-11 08:02:21 +0000 etc/sandbox.conf: allow /usr/tmp/ for write In bug #737220 sandbox was denying write access to /usr/tmp (a symlink to /var/tmp) for statically linked binaries. It happens because erealpath() helper conservatively does not resolve any symlink for external traced processes (to avoid symlink confusion via /proc/ that could refer to tracer and not tracee). Instead of fixing erealpath() to handle more cases of symlinks let's just allow /usr/tmp as if it was /var/tmp. Reported-by: Kirill Chibisov Bug: https://bugs.gentoo.org/737220 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> etc/sandbox.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) sandbox-2.21 should handle it with more grace and treat /usr/tmp as temporary dir. |
When trying to emerge sys-apps/coreutils-8.3{1,2}-r1. I'm getting the following sandbox error. I already emerged `sys-apps/coreutils-8.31-r1 somehow in the past without issues, however right now it's failing as well. I feel like it could be related to having `+static` on coreutils. Reproducible: Always Steps to Reproduce: emerge --oneshot coreutils Actual Results: sandbox violation. Expected Results: package emerges without issues.