Created attachment 397070 [details] build.log Not sure if this is somehow my fault or what, but gtk-vnc is tosses a weird looking error: F: open_wr S: deny P: /dev/stderr A: /dev/stderr R: /dev/stderr C: /bin/sh /usr/bin/pygtk-codegen-2.0 --prefix gtkvnc --register /usr/share/pygtk/2.0/defs/gdk-types.defs --register /usr/share/pygtk/2.0/defs/gtk-types.defs --override /var/tmp/portage/net-libs/gtk-vnc-0.5.4/work/gtk-vnc-0.5.4/src/vnc.override vnc.defs
This is usually related with some problem with the /dev/std* on your setup: https://bugs.gentoo.org/show_bug.cgi?id=487080 https://bugs.gentoo.org/show_bug.cgi?id=288863 https://bugs.gentoo.org/show_bug.cgi?id=286660
This bug seems to be back from the dead. I am willing to allow any kind of troubleshooting you wish. [ebuild R ~] sys-apps/portage-2.2.17::gentoo USE="(ipc) subversion (xattr) (-build) -cvs -doc -epydoc -git (-selinux)" LINGUAS="-ru" PYTHON_TARGETS="python2_7 python3_3 -pypy -python3_4" 0 KiB [ebuild R ] sys-apps/sandbox-2.6-r1::gentoo USE="(multilib)" 0 KiB new-host-4 ~ # ls -ld /dev/std* lrwxrwxrwx 1 root root 15 Feb 16 22:01 /dev/stderr -> /proc/self/fd/2 lrwxrwxrwx 1 root root 15 Feb 16 22:01 /dev/stdin -> /proc/self/fd/0 lrwxrwxrwx 1 root root 15 Feb 16 22:01 /dev/stdout -> /proc/self/fd/1
thanks to a few helpful ideas from zmedico I've got some useful output. /usr/bin/pygtk-codegen-2.0 is a bash script so I edited it and added the following: readlink -f /dev/stderr > $T/stderr 2>&1 ls -al $(readlink -f /dev/stderr) >> $T/stderr 2>&1 And the resulting file shows: /var/tmp/portage/net-libs/gtk-vnc-0.5.4/temp/stderr ls: cannot access /tmp/tmpf0ctZFR: No such file or directory ls: cannot access (deleted): No such file or directory Not really sure what is going on there, but I'm guessing it's interesting. Super interesting (to me) is that with FEATURES="-usersandbox sandbox" it gets the same errors in my $T/stderr file but sandbox doesn't care. I'm at a loss to explain this, I simply lack the experience.
This is the offending file (pygtk-codegen-2.0) in its entirety: #! /bin/sh prefix=/usr exec_prefix=${prefix} pygobject_script=${exec_prefix}/bin/pygobject-codegen-2.0 echo "note: pygtk-codegen-2.0 is deprecated, use pygobject-codegen-2.0 instead" > /dev/stderr echo "note: I will now try to invoke pygobject-codegen-2.0 in the same directory" > /dev/stderr exec $pygobject_script "$@" If I comment out the two echo lines, the sandbox violation disappears.
[ebuild R ] dev-python/pygtk-2.24.0-r4:2::gentoo USE="-doc -examples {-test}" PYTHON_TARGETS="python2_7" 0 KiB
so /dev/stderr does exist and is not (ultimately) a broken link ? what if you do: readlink -f /dev/stderr where does that point ? it's a bit weird that, if /dev/stderr is a symlink, sandbox didn't dereference it for you in the log output ...
(In reply to SpanKY from comment #6) > so /dev/stderr does exist and is not (ultimately) a broken link ? It is a broken link, with readlink in /proc/self/fd/2 returning the string "/tmp/tmpf0ctZFR (deleted)". You can infer this from the "ls: cannot access (deleted): No such file or directory" message shown in comment #3. > what if you do: > readlink -f /dev/stderr > where does that point ? "/tmp/tmpf0ctZFR (deleted)" > it's a bit weird that, if /dev/stderr is a symlink, sandbox didn't > dereference it for you in the log output ... Probably because the file doesn't exist.
(In reply to Zac Medico from comment #7) yes, but sandbox should be showing the target even if it's broken. especially since that's important to us when open() will dereference the target. i can reproduce this in an ebuild: src_prepare() { exec 2> "${T}"/foo echo pass >/dev/stderr rm "${T}"/foo echo fail >/dev/stderr } >>> Preparing source in /var/tmp/portage/app-misc/pax-utils-1.0.2/work/pax-utils-1.0.2 ... * ACCESS DENIED: open_wr: /dev/stderr >>> Source prepared. * --------------------------- ACCESS VIOLATION SUMMARY ---------------------- * LOG FILE: "/var/log/sandbox/sandbox-13465.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 /usr/lib/portage/python2.7/ebuild.sh prepare * ---------------------------------------------------------------------------
(In reply to SpanKY from comment #6) > it's a bit weird that, if /dev/stderr is a symlink, sandbox didn't > dereference it for you in the log output ... My comment 0 seems to look like your comment 8. Not sure what you want me to do from here. As far as I can tell at some point /dev/stderr is a broken symlink, but for all I know my testing methodology could be wrong. That said, I literally put the test case one line above the "echo blah > /dev/stderr" line that causes the violation so I'm not sure how else to test. I can easily edit pygtk-codegen-2.0 and put anything in there that you like and provide results. This bug is 100% reproducible for me.
(In reply to Rick Farina (Zero_Chaos) from comment #9) i don't "need" you or anyone else here to do stuff (i don't mean that to sound dickish; it's simply the facts). we've got the minimal test case that is independent of any package. the next step is to actually fix the bug. if someone wants to dive into sandbox they certainly can, otherwise it'll wait for me to circle around to doing more sandbox fixes. this doesn't seem like a super critical issue.
(In reply to SpanKY from comment #10) > i don't "need" you or anyone else here to do stuff (i don't mean that to > sound dickish; it's simply the facts). Trust me, no offense taken. I'd rather be useless here as I'm above my head :-) > otherwise it'll wait for me to circle around to doing more sandbox fixes. this > doesn't seem like a super critical issue. Cool, I'll look into my thunderbird issue that appears to be sandbox related then, that should help the motivation to work on sandbox.
this basically boils down to sandbox not dereferencing broken symlinks. if a symlink points to a file that exists, then we check the fully resolved target. if the target is missing, then we don't use that path for checking. this bites us in two ways: (1) as documented here, if the symlink itself is in a denied directory (e.g. /dev), then we end up throwing a violation even if the target is in an OK location (2) if the symlink is in a good place but points to a bad place, then we *don't* throw a violation when we should have an example of the latter: ln -s /foo "${WORKDIR}"/foo echo oops >"${WORKDIR}"/foo <not caught> unfortunately, it looks like the functions the C library provides (and the helpers sandbox already has) fall into two buckets: (1) dereference a single symlink (so a symlink to a symlink to a file will return a path to the second symlink and not the last file) (2) dereference *all* symlinks, except if the final target doesn't exist, return an error really we want the equiv of `readlink -f`. which means i'm going to have to implement it myself. we actually saw this somewhat in the past when /dev/std* were pipes/sockets in bug 288863.
this should be fixed in sandbox-2.8 by: http://gitweb.gentoo.org/proj/sandbox.git/commit/?id=105b7e047e98e8f9211a30133d0cc1cb97aef9b0 http://gitweb.gentoo.org/proj/sandbox.git/commit/?id=93d401570d4e54f732c0f821cdbb5ba2e1dee0f3
