Summary: | sys-apps/sandbox: unable to load libsandbox.so via LD_PRELOAD when filecaps are in use | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Bruno <bonbons> |
Component: | New packages | Assignee: | Sandbox Maintainers <sandbox> |
Status: | RESOLVED CANTFIX | ||
Severity: | normal | CC: | ahipp0, netbox253, rajiv, rossi.f |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | /bin/ls, /bin/mv, /usr/lib/libsandbox.so |
Description
Bruno
2009-04-18 18:34:10 UTC
Please run FEATURES="-sandbox" emerge -1 sandbox and report wether this fixed your problem. If yes, mark this bug as duplicate of bug #265895 Reopen this bug when you provide the requested information. (In reply to comment #1) > Please run > > FEATURES="-sandbox" emerge -1 sandbox > > and report wether this fixed your problem. If yes, mark this bug as duplicate > of bug #265895 Running FEATURES="-sandbox" emerge -1 sandbox (still shows the error message) then emerge --oneshot portage and I still get the same error. I also removed sandbox from FEATURES in /etc/make.conf, reemerged sandbox and portage, but when I readd sandbox to FEATURES the same error is back again. make sure you dont have any stray libsandbox.so libs laying around in your system. there should only be the one in /usr/lib/. try running `sandbox` manually and then a few programs to see if you get the same error. I tried to find out on which commands portage triggers the ERROR message. To do this I added " -x" to first line of /usr/lib/portage/bin/ebuild.sh This produced a lot of output including the following lines: + mv /var/tmp/portage/sys-apps/portage-2.1.6.7/temp/environment.filtered /var/tmp/portage/sys-apps/portage-2.1.6.7/temp/environment ERROR: ld.so: object 'libsandbox.so' from LD_PRELOAD cannot be preloaded: ignored. I tried to reproduce it manually by calling mv and also got the error: me # sandbox mv dummy dummy1 sandbox mv dummy dummy1 ERROR: ld.so: object 'libsandbox.so' from LD_PRELOAD cannot be preloaded: ignored. Running the same as root does not complain, running as user portage complains again. So it looks like sandbox cannot be loaded properly as normal user for *some* commands but has no issues for others. me # sandbox /bin/ls / OK me # sandbox /bin/mv --help ERROR Both ls and mv come from coreutils I also scanned my system for files containing sandbox in their names and all I found (in /bin, /sbin, /lib, /usr) were: /usr/bin/sandbox.orig /usr/bin/sandbox /usr/lib/libsandbox.la /usr/lib/libsandbox.so /usr/lib/python2.5/site-packages/setuptools/sandbox.py /usr/lib/python2.5/site-packages/setuptools/sandbox.pyc /usr/lib/python2.5/site-packages/setuptools/sandbox.pyo /usr/share/cvs/contrib/sandbox_status /usr/share/doc/sandbox-1.6-r2 /usr/share/sandbox /usr/share/sandbox/sandbox.bashrc So there is definitely no stale sandbox version hanging around. /usr/bin/sandbox.orig obviously shouldnt exist what does `file` show when run on ls and mv ? what are the permissions on the libsandbox.so library ? Created attachment 189528 [details]
/bin/ls, /bin/mv, /usr/lib/libsandbox.so
The sandbox.orig is me renaming /usr/bin/sandbox and putting a replacement shell wrapper calling the original instance after printing out the command line (was in order to determine callers of sandbox during emerge so I could catch failing apps more quickly)
I notice no real difference between mv and ls. In case you want to have a look at the binaries themselves, I attached /bin/ls, /bin/mv and /usr/lib/sandbox.so (in a tar archive).
strace on /bin/mv did not show anything useful either:
...
[pid 22917] open("/usr/lib/sse2/libsandbox.so", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 22917] stat64("/usr/lib/sse2", 0xbfdd6884) = -1 ENOENT (No such file or directory)
[pid 22917] open("/usr/lib/libsandbox.so", O_RDONLY) = 3
[pid 22917] read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\33\0\0004\0\0\0\274"..., 512) = 512
[pid 22917] fstat64(3, {st_mode=S_IFREG|0755, st_size=50636, ...}) = 0
[pid 22917] close(3) = 0
[pid 22917] writev(2, [{"ERROR: ld.so: object '"..., 22}, {"libsandbox.so"..., 13}, {"' from "..., 7}, {"LD_PRELOAD"..., 10}, {" cannot be preloaded: ignored.\n"..., 31}], 5ERROR: ld.so: object 'libsandbox.so' from LD_PRELOAD cannot be preloaded: ignored.
) = 83
file /bin/mv
/bin/mv: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), stripped
file /bin/ls
/bin/ls: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), stripped
ls -l /usr/lib/libsandbox.so
-rwxr-xr-x 1 root root 50636 2009-04-23 18:19 /usr/lib/libsandbox.so
Ok, now I know what's the detail to cause this. Here are the full steps (should work on any system with CONFIG_SECURITY_FILE_CAPABILITIES=y: root# emerge sys-apps/coreutils root# touch /tmp/dummy rout# mv /tmp/dummy /tmp/dummy1 root# setcap "cap_setfcap=ie cap_chown=ie" /bin/mv root# mv /tmp/dummy1 /tmp/dummy root# setcap -r /bin/mv root# mv /tmp/dummy /tmp/dummy1 Repeating the same as a normal user: user# su root# emerge sys-apps/coreutils root# exit user# touch /tmp/dummy user# mv /tmp/dummy /tmp/dummy1 user# su root# setcap "cap_setfcap=ie cap_chown=ie" /bin/mv root# exit user# mv /tmp/dummy1 /tmp/dummy ERROR: ld.so: object 'libsandbox.so' from LD_PRELOAD cannot be preloaded: ignored. user# su root# setcap -r /bin/mv root# exit user# mv /tmp/dummy /tmp/dummy1 So for some reason sandbox loading fails when file-capabilities are used to restrict what capabilities a process may get... you set those file caps yourself right ? i'm not aware of any ebuild doing this for you. off the top of my head though, i dont know why it would make any difference at all (In reply to comment #10) > you set those file caps yourself right ? i'm not aware of any ebuild doing > this for you. Exact, I played a bit with file caps. Don't know any ebuild that would handle file caps (there was a thread on gentoo-dev about file caps some time ago, but I have not heard of anything hitting the tree) > off the top of my head though, i dont know why it would make any difference at > all Especially those flags I did set for mv should not have any affect for a system user (they should just reduce caps for root). Not that I know how file capabilities work, so maybe of less help at all, but I just have seen this in Prefix on RHEL 5.2 (does not cause the merge to stop): ACCESS DENIED open_wr: /selinux/context i think dont think that is related in any way to this bug I hit this bug on a stable x86 system while trying to install games-rpg/nwn-data. The ebuild fall into an endless loop like this : > >>> Unpacking source... > ERROR: ld.so: object 'libsandbox.so' from LD_PRELOAD cannot be preloaded: ignored. > Please insert your first Neverwinter Nights CD/DVD into your drive and > press any key to continue > ERROR: ld.so: object 'libsandbox.so' from LD_PRELOAD cannot be preloaded: ignored. > Please insert your first Neverwinter Nights CD/DVD into your drive and > press any key to continue > ^C I must hit ctrl+c to abort. I then read the nwn-data ebuild, and found that the CD_ROOT autodetection is broken for me because the mount command always return this error if executed into the sandbox without root privileges (FEATURES="userpriv"). > $ sandbox mount > ERROR: ld.so: object 'libsandbox.so' from LD_PRELOAD cannot be preloaded: ignored. > /dev/sda1 on / type ext4 (rw,noatime) The workaround for me is simple : export CD_ROOT="/my/cd/path" before emerging nwn-data, but now I know that CD autodetection from ebuilds is broken for me. sandbox-1.6-r2 installed. I also run into this problem with a machine running X86_64 version. Looks like libsandbox.so/la are installed into /usr/lib32 and /usr/lib64. My fix is creating symlinks from /usr/lib32/libsandbox.so/la to /usr/lib/libsandbox.so/la. sys-apps/sandbox-1.6-r2 must has a bug at least for x86_64 version. Simon A better solution is to add /usr/lib32 and /usr/lib64 to /etc/ld.so.conf file. Then run ldconfig. Simon that has nothing to do with this bug, nor do i know what you're talking about. open a new bug for your issue with proper info & full logs. thinking about it some more, i think this is expected behavior. you're running with FEATURES=userpriv, and setting capabilities on a program have pretty much the same general practical implications of doing set*id on the binary. since you're executing `mv` as non-root, glibc's ldso will ignore LD_PRELOAD for security protection (ignore symbol interposition, constructors, etc...). in other words, i dont think there's any way this can be "fixed". |