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 ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1-20191014-001639 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-9.2.0 * clang: clang version 9.0.0 (tags/RELEASE_900/final) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/9/bin llvm: 9.0.0 Available Python interpreters, in order of preference: [1] python3.6 [2] python2.7 (fallback) [3] pypy3 (fallback) [4] pypy (fallback) Available Ruby profiles: [1] ruby24 (with Rubygems) [2] ruby25 (with Rubygems) * Available Rust versions: [1] rust-1.38.0 * repository: ==> /var/db/repos/gentoo/metadata/timestamp.chk <== Fri, 18 Oct 2019 07:06:12 +0000 emerge -qpvO app-emulation/libpod [ebuild N ] app-emulation/libpod-1.6.2 USE="rootless -apparmor -btrfs -ostree (-selinux)"
Created attachment 593240 [details] emerge-info.txt
Created attachment 593242 [details] app-emulation:libpod-1.6.2:20191018-071108.log.bz2
Created attachment 593244 [details] emerge-history.txt
Created attachment 593246 [details] etc.portage.tbz2
Created attachment 593248 [details] logs.tbz2
Created attachment 593250 [details] sandbox-4.log
(In reply to Toralf Förster from comment #6) > Created attachment 593250 [details] > sandbox-4.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: /dev/stderr > A: /dev/stderr > R: /dev/stderr > C: /bin/bash hack/get_release_info.sh NUMBER > > F: open_wr > S: deny > P: /dev/stderr > A: /dev/stderr > R: /dev/stderr > C: /bin/bash hack/get_release_info.sh NUMBER This is strange, because /dev/stderr is normally safe for write in sandbox. I see sys-apps/sandbox-2.18 has been available for a few months, and it seems like we would have seen a lot of similar failures if it didn't normally allow write to /dev/stderr.
(In reply to Zac Medico from comment #7) > > This is strange, because /dev/stderr is normally safe for write in sandbox. > I see sys-apps/sandbox-2.18 has been available for a few months, and it > seems like we would have seen a lot of similar failures if it didn't > normally allow write to /dev/stderr. The issue is reproducible with this package at different tinderbox images.
I'm seeing this issue myself (with sys-apps/sandbox-2.13), but just in some container builds which are using buildah inside of docker. I committed a container afterwards and when looked inside I found that /dev/stderr appears to be normal: > 9a12014a3d17 / # ls -l /dev/stderr > lrwxrwxrwx 1 root root 15 Nov 9 22:19 /dev/stderr -> /proc/self/fd/2
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3af85c99a2df7943f9476f5cd67d4c526b622fe2 commit 3af85c99a2df7943f9476f5cd67d4c526b622fe2 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2019-11-09 22:46:44 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2019-11-09 22:51:54 +0000 app-emulation/libpod: fix get_release_info.sh VERSION Bug: https://bugs.gentoo.org/697998 Package-Manager: Portage-2.3.79, Repoman-2.3.18 Signed-off-by: Zac Medico <zmedico@gentoo.org> app-emulation/libpod/libpod-1.6.3.ebuild | 3 +++ 1 file changed, 3 insertions(+)
(In reply to Larry the Git Cow from comment #10) That prevented the sandbox violation for me.
