After uprading portage from 2.1.6.13 to 2.1.7.1 emerging gajim fails on: >>> Source compiled. --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE "/var/log/sandbox/sandbox-18486.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/sh /usr/bin/pygtk-codegen-2.0 --prefix trayicon --register /usr/share/pygtk/2.0/defs/gdk-types.defs --register /usr/share/pygtk/2.0/defs/gtk-types.defs --override ./trayicon.override ./trayicon.defs F: open_wr S: deny P: /dev/stderr A: /dev/stderr R: /dev/stderr C: /bin/sh /usr/bin/pygtk-codegen-2.0 --prefix trayicon --register /usr/share/pygtk/2.0/defs/gdk-types.defs --register /usr/share/pygtk/2.0/defs/gtk-types.defs --override ./trayicon.override ./trayicon.defs -------------------------------------------------------------------------------- >>> Failed to emerge net-im/gajim-0.12.1, Log file Reproducible: Always
Created attachment 206953 [details] build log
Created attachment 206954 [details] emerge --info
It doesn't fail with the old portage version?
Yes, with portage-2.1.6.13 it compiles cleanly.
Please attach the build log with portage-2.1.6.13. Use FEATURES="keeptemp" to prevent the build.log from being removed.
Created attachment 206959 [details] build log , portage-2.1.6.13
It's probably related to bug 258684.
please post the output of: ls -l /dev/std* /dev/fd
Here you are: # ls -l /dev/std* /dev/fd lrwxrwxrwx 1 root root 13 2009-10-14 /dev/fd -> /proc/self/fd lrwxrwxrwx 1 root root 4 2009-10-14 /dev/stderr -> fd/2 lrwxrwxrwx 1 root root 4 2009-10-14 /dev/stdin -> fd/0 lrwxrwxrwx 1 root root 4 2009-10-14 /dev/stdout -> fd/1
those all look right. dare i ask if /proc/self/fd/ is sane ? what happens if you run on the command line: sandbox echo moo > /dev/stderr
(In reply to comment #10) > those all look right. dare i ask if /proc/self/fd/ is sane ? But for which process? For example: # ls -lah /proc/self/fd/ razem 0 dr-x------ 2 root root 0 10-14 13:05 . dr-xr-xr-x 6 root root 0 10-14 13:05 .. lrwx------ 1 root root 64 10-14 13:05 0 -> /dev/pts/2 lrwx------ 1 root root 64 10-14 13:05 1 -> /dev/pts/2 lrwx------ 1 root root 64 10-14 13:05 2 -> /dev/pts/2 lr-x------ 1 root root 64 10-14 13:05 3 -> /proc/30640/fd marcinm proc # > what happens if you run on the command line: > sandbox > echo moo > /dev/stderr Looks ok.. # sandbox ============================= Gentoo path sandbox ============================== Detection of the support files. Verification of the required files. Setting up the required environment variables. The protected environment has been started. -------------------------------------------------------------------------------- Process being started in forked instance. * Loading sandboxed shell * Log File: /var/log/sandbox/sandbox-24280.log * Debug Log File: /var/log/sandbox/sandbox-debug-24280.log * sandboxon: turn sandbox on * sandboxoff: turn sandbox off * addread <path>: allow <path> to be read * addwrite <path>: allow <path> to be written * adddeny <path>: deny access to <path> * addpredict <path>: allow fake access to <path> [s] marcinm proc # echo moo > /dev/stderr moo [s] marcinm proc #
User sandbox can't write to /dev/stderr .. su -c sandbox -s /bin/bash portage ============================= Gentoo path sandbox ============================== Detection of the support files. Verification of the required files. Setting up the required environment variables. The protected environment has been started. -------------------------------------------------------------------------------- Process being started in forked instance. * Loading sandboxed shell * Log File: /var/log/sandbox/sandbox-15338.log * Debug Log File: /var/log/sandbox/sandbox-debug-15338.log * sandboxon: turn sandbox on * sandboxoff: turn sandbox off * addread <path>: allow <path> to be read * addwrite <path>: allow <path> to be written * adddeny <path>: deny access to <path> * addpredict <path>: allow fake access to <path> [s] portage@marcinm /proc $ echo moo > /dev/stderr bash: /dev/stderr: Permission denied [s] portage@marcinm /proc $
(In reply to comment #12) Sorry, user portage..;)
that is a different issue. notice how it didnt trigger a sandbox violation. you've changed your uid to portage, but you didnt launch a new pty, so the current pty is still owned by root. can you emerge netpbm ?
Netpbm emerge without any problem.
There is a similar bug for another package: bug 288874. It was marked as duplicate of bug 286660.
guess i should enhance the violation summary to dereference symlinks i dont suppose your /bin/sh is a static binary ? file -L /bin/sh
*** Bug 286660 has been marked as a duplicate of this bug. ***
No. It is not static binary: # file -L /bin/sh /bin/sh: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
i guess if you edit /usr/bin/pygtk-codegen-2.0 and change "/dev/stderr" to "1>&2", things "work" ?
Yeah, it's fixing the problem :)
hrm, i wish i could reproduce this issue on my side to poke it deeper if you edit the gajim ebuild and add: src_unpack() { unpack ${A}; echo > /dev/stderr; } does that trigger the failure ?
Yes, it does. ACCESS DENIED open_wr: /dev/stderr /var/tmp/portage/net-im/gajim-0.12.1/temp/environment: line 3429: /dev/stderr: Permission denied
i'm guessing that also doing `touch /dev/stderr` fails ? if so, try doing: SANDBOX_DEBUG=yes strace -f -s 4096 -vvv -o log touch /dev/stderr then post the "log" file as an attachment and the sandbox output as a comment
(In reply to comment #24) > i'm guessing that also doing `touch /dev/stderr` fails ? No. # touch /dev/stderr # > if so, try doing: > SANDBOX_DEBUG=yes strace -f -s 4096 -vvv -o log touch /dev/stderr Don't you mean: SANDBOX_DEBUG=yes strace -f -s 4096 -vvv -o log sandbox touch /dev/stderr ?
no, because running sandbox inside of sandbox wont work i'm not talking about errors at the command prompt, i'm talking about sb violations inside of the ebuild so use: src_unpack() { unpack ${A} SANDBOX_DEBUG=yes strace -f -s 4096 -vvv -o log touch /dev/stderr } if the touch doesnt fail, try: sh -c '> /dev/stderr'
Created attachment 207085 [details] sandbox+strace log >>> Unpacking source... >>> Unpacking gajim-0.12.1.tar.gz to /var/tmp/portage/net-im/gajim-0.12.1/work ACCESS ALLOWED execve: /usr/bin/strace ACCESS ALLOWED open_rd: /usr/bin/strace ACCESS ALLOWED open_wr: /var/tmp/portage/net-im/gajim-0.12.1/work/log ACCESS ALLOWED execv: /usr/bin/touch ACCESS ALLOWED open_rd: /usr/bin/touch ACCESS DENIED open_wr: /dev/stderr ACCESS DENIED utimensat: /dev/stderr touch: cannot touch `/dev/stderr': Permission denied >>> Source unpacked in /var/tmp/portage/net-im/gajim-0.12.1/work --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE "/var/log/sandbox/sandbox-10709.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: touch /dev/stderr F: utimensat S: deny P: /dev/stderr A: /dev/stderr R: /dev/stderr C: touch /dev/stderr --------------------------------------------------------------------------------
looks like it's because your stderr is a pipe 10754 readlink("/proc/10754/fd/2", "pipe:[402562]"..., 4095) = 13 10754 lstat64("/proc/10754/fd/pipe:[402562]", 0xbfb13ddc) = -1 ENOENT (No such file or directory) this can be checked quickly by doing: $ sandbox 'echo | touch /dev/stdin' ACCESS DENIED open_wr: /dev/stdin ACCESS DENIED utimensat: /dev/stdin touch: cannot touch `/dev/stdin': Permission denied why exactly is your std* a pipe ? is there some portage logging option that sets this up ?
> looks like it's because your stderr is a pipe [...] > why exactly is your std* a pipe ? is there some portage logging option that > sets this up ? I don't know what to say. I didn't set up stderr as a pipe intentionally, and i didn't setup any super-extra option for portage logging. Could it be releated to udev?
i'm not suggesting it's your fault or it's something you need to resolve, i'm just curious how that happened. it was more of a question for Zac.
(In reply to comment #28) > why exactly is your std* a pipe ? is there some portage logging option that > sets this up ? Logging goes through a pipe if pty devices can't be used for some reason: 1) there are no pty devices 2) bug #287648 (workaround for upstream python3 issue)
(In reply to comment #22) > hrm, i wish i could reproduce this issue on my side to poke it deeper You can force pipes by setting _disable_openpty = True inside pym/portage/__init__.py, or installing portage with USE=python3.
(In reply to comment #31) [...] > 2) bug #287648 (workaround for upstream python3 issue) After emerging portage with USE="-python3" , gajim compiles cleanly. It was long way;)
I've added a temporary workaround for portage in svn r14612.
*** Bug 282514 has been marked as a duplicate of this bug. ***
*** Bug 289876 has been marked as a duplicate of this bug. ***
*** Bug 290059 has been marked as a duplicate of this bug. ***
Maybe it will be better to just fix pygtk? It seems to be much faster and much better idea, at least for me. Anyway, usage of /dev/stderr directly is bad style.
other packages are broken by this change. i'll probably get some time in the next few days to fix sandbox.
z-esprimo ~ # eselect python list Available python interpreters: [1] python2.6 * [2] python3.1 z-esprimo ~ # eselect python set 2 Fix same problem with gnome-extra/libgsf-1.14.16.
technically, same issue could come up if the fd were any sort of weird anonymous file like a socket: or whatever else the kernel/userland threw at us. ive changed the code to ignore broken /proc/*/fd/ symlinks which have a colon in their name like "pipe:[6257865]" or "socket:[6257866]" or ... this is in sandbox-2.2 now http://git.overlays.gentoo.org/gitweb/?p=proj/sandbox.git;a=commitdiff;h=f23b9bef900c89c8a4e7c4e220570198257fe03b
Thanks, it works :)
There's a workaround in portage-2.1.7.2 and portage-2.2_rc47 depends on sandbox-2.2.
