Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 737220 - sys-apps/coreutils-8.3{1,2}-r1[static]: sandbox violation on /usr/tmp/
Summary: sys-apps/coreutils-8.3{1,2}-r1[static]: sandbox violation on /usr/tmp/
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: AMD64 Linux
: Normal normal (vote)
Assignee: Sandbox Maintainers
URL:
Whiteboard:
Keywords: PATCH
Depends on:
Blocks:
 
Reported: 2020-08-15 07:36 UTC by Kirill Chibisov
Modified: 2020-10-31 20:08 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
build.log (build.log,50.49 KB, text/plain)
2020-08-15 07:37 UTC, Kirill Chibisov
Details
emerge --info output (emerge-info.txt,5.89 KB, text/plain)
2020-08-15 07:39 UTC, Kirill Chibisov
Details
0001-etc-sandbox.conf-allow-usr-tmp-for-write.patch (0001-etc-sandbox.conf-allow-usr-tmp-for-write.patch,1.25 KB, patch)
2020-10-23 07:13 UTC, Sergei Trofimovich
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Kirill Chibisov 2020-08-15 07:36:54 UTC
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.
Comment 1 Kirill Chibisov 2020-08-15 07:37:59 UTC
Created attachment 654734 [details]
build.log
Comment 2 Kirill Chibisov 2020-08-15 07:39:30 UTC
Created attachment 654736 [details]
emerge --info output
Comment 3 Sam James archtester gentoo-dev Security 2020-10-22 17:55:27 UTC
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.)
Comment 4 Sam James archtester gentoo-dev Security 2020-10-22 17:55:54 UTC
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.
Comment 5 Mike Gilbert gentoo-dev 2020-10-22 18:19:40 UTC
Passing this over to the sandbox maintainer to take a look.
Comment 6 Thomas Deutschmann gentoo-dev Security 2020-10-22 18:31:00 UTC
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.
Comment 7 jernej.jakob+gentoo 2020-10-22 18:53:23 UTC
(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.
Comment 8 Kirill Chibisov 2020-10-22 19:12:12 UTC
>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.
Comment 9 Thomas Deutschmann gentoo-dev Security 2020-10-22 19:14:04 UTC
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.
Comment 10 Kirill Chibisov 2020-10-22 19:55:11 UTC
>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).
Comment 11 Kirill Chibisov 2020-10-22 21:32:53 UTC
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...
Comment 12 Sergei Trofimovich gentoo-dev 2020-10-22 21:40:38 UTC
(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.
Comment 13 Sergei Trofimovich gentoo-dev 2020-10-23 07:13:44 UTC
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.
Comment 14 Sergei Trofimovich gentoo-dev 2020-10-31 20:08:31 UTC
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)