Hello, Let me start this report with 1.2.* work fine on my RHEL 5 box in a Gentoo Prefix env. 1.2.20_alpha2-r1 is the base for my upgrade regressions, I will always be upgrading to newer versions from this version. 1.3.0 install fails with: ../../sandbox-1.3.0/libsandbox/wrapper-funcs/lutimes.c: In function ‘lutimes_DEFAULT’: ../../sandbox-1.3.0/libsandbox/wrapper-funcs/lutimes.c:16: error: ‘AT_FDCWD’ undeclared (first use in this function) make[2]: *** [libsandbox_la-wrappers.lo] Error 1 make[2]: *** Waiting for unfinished jobs.... ../../sandbox-1.3.0/libsandbox/libsandbox.c: In function ‘before_syscall’: ../../sandbox-1.3.0/libsandbox/libsandbox.c:900: error: ‘AT_FDCWD’ undeclared (first use in this function) ../../sandbox-1.3.0/libsandbox/libsandbox.c:900: error: (Each undeclared identifier is reported only once ../../sandbox-1.3.0/libsandbox/libsandbox.c:900: error: for each function it appears in.) 1.3.1 install fails the same. 1.3.2 install works but then I get this on every(?) sandbox call: ERROR: ld.so: object 'libsandbox.so' from LD_PRELOAD cannot be preloaded: ignored.
how older versions fail really doesnt matter. only the latest is relevant.
the warning is because the place you installed libsandbox.so is not in ld.so.conf
btw, the implied question is, how are you supposed to work with libraries that are not in ld.so.conf or the default library search path ? how does library lookup work at all for prefix ?
(In reply to comment #3) > btw, the implied question is, how are you supposed to work with libraries that > are not in ld.so.conf or the default library search path ? how does library > lookup work at all for prefix ? for ELF we add rpath entries for lib and usr/lib to RPATH, e.g.: % scanelf --rpath /Library/Gentoo/usr/lib/libzzip.so TYPE RPATH FILE ET_DYN /Library/Gentoo/usr/i386-pc-solaris2.10/lib/gcc:/Library/Gentoo/usr/i386-pc-solaris2.10/lib:/Library/Gentoo/usr/lib:/Library/Gentoo/lib /Library/Gentoo/usr/lib/libzzip.so where /Library/Gentoo is my offset prefix.
essential bit: rpath links are injected by the linker wrapper, such that the offset becomes sort of transparent to the user. For includes we modified gcc to look into our offset by default. You can find some of our theory and practice described here: http://dev.gentoo.org/~grobian/gleps/glep-prefix.html#dynamic-libraries-approach
changing libsbutil/get_sandbox_lib.c like so will probably fix the issue here. but it wont work for multilib systems ... void get_sandbox_lib(char *path) { save_errno(); strcpy(path, LIB_NAME); if (strncmp("/usr/lib", LIBSANDBOX_PATH, 8)) { void *hndl = dlopen(path, RTLD_LAZY); if (!hndl) snprintf(path, SB_PATH_MAX, "%s/%s", LIBSANDBOX_PATH, LIB_NAME); else dlclose(hndl); } restore_errno(); }
btw, someone needs to test what i proposed before i commit it ...
(In reply to comment #7) > btw, someone needs to test what i proposed before i commit it ... > I did, it failed to link. I was working on a modded patch but couldn't get it to work. Will attach a log tomorrow if I have time.
right, you probably need to update src/Makefile.am to add -ldl to sandbox_LDADD
(In reply to comment #9) > right, you probably need to update src/Makefile.am to add -ldl to sandbox_LDADD > Looks good, got it to work. At least, there is no runtime ERROR like there use to be. Should I patch it in prefix or will this eventually be in a release?
you guys shouldnt be patching sandbox in any way. i'll add it to the next release.
added to git: http://git.overlays.gentoo.org/gitweb/?p=proj/sandbox.git;a=commitdiff;h=1d8dac7eee63b01e70239872e297d60994f08865
(In reply to comment #12) > added to git: > http://git.overlays.gentoo.org/gitweb/?p=proj/sandbox.git;a=commitdiff;h=1d8dac7eee63b01e70239872e297d60994f08865 > Sorry, this error still happens with 1.3.3. Did the commit make it to that release?
the log shows that it was: http://git.overlays.gentoo.org/gitweb/?p=proj/sandbox.git;a=shortlog
(In reply to comment #14) > the log shows that it was: > http://git.overlays.gentoo.org/gitweb/?p=proj/sandbox.git;a=shortlog > Wierd, give me a few days here to short this out then.
Is it the only known sandbox-1.3.2 "bug"? I would really like to have it stabilized - this particular version never caused any problems for me and it solves issues with KDE4 packages (cmake related bug).
this bug doesnt affect any "standard" system
any news ?
Still doesn't work for darkside. Can LD_PRELOAD contain an absolute path to the lib?
(In reply to comment #19) > Still doesn't work for darkside. Can LD_PRELOAD contain an absolute path to > the lib? > at least on interix it works, since thats what i'm doing for the fork problem on vista/server2008.
by "news" i meant "figure out what's wrong". sandbox uses a full path for all installs that dont go into /usr/lib.
(In reply to comment #21) > by "news" i meant "figure out what's wrong". sandbox uses a full path for all > installs that dont go into /usr/lib. > Sorry, this stuff is way over my head. Comment #6 fixed this issue and the next release that had the "fix" committed didn't work. So, no, I can't figure out what's wrong. =/
(In reply to comment #21) > by "news" i meant "figure out what's wrong". sandbox uses a full path for all > installs that dont go into /usr/lib. > Well, it doesn't really do that. At least not in get_sandbox_lib(). The problem is how the ELF-linker looks up the library. The easiest ways are by relative/absolute path and ld.so.conf. But there's some other mechanism that is triggered in prefix: If the executable calling dlopen() has rpath set up (DT_RPATH or DT_RUNPATH) in its ELF-header, ld will use those paths to find libsandbox.so. This mechanism actually triggers in get_sandbox_lib(). If you invoke sandbox in prefix, it is set up with rpath and has it set to the directory where libsandbox.so resides, thus that function *is* able to load libsandbox.so any time you invoke it. Your hdnl-check will always use the else-branch and hence the library path in that char* path will always be "libsandbox.so". While this works for prefixed applications (i.e. applications with rpath) any invoked non-prefixed application will fail with that LD_PRELOAD error, since ld can't make use of DT_RPATH or DT_RUNPATH there and won't be able to make use of "libsandbox.so" contained in that path variable. You can verify that behaviour by attaching gdb to get_sandbox_lib() and simply test the 'fix' by invoking "snprintf(path, SB_PATH_MAX, "%s/%s", "${EPREFIX}/usr/lib", LIB_NAME);" in that function. When retuning that value, applications invoked within sandbox are able to find that library by only the means of the ELF-ld. I tested non-prefixed bash and emerging of kde-base/systemsettings on my amd64-linux prefix. Without the absolute path returned, that bash would fail with massive errors about not finding libsandbox.so, and kde-base/systemsettings the used cmake would have broken build and library lookup with things like "kfontinst_LIB_DEPENDS:STATIC=general;KDE4__kio;general;ERROR: ld.so: object 'libsandbox.so' from LD_PRELOAD cannot be preloaded: ignored.-L/Gentoo/usr/lib -lfreetype -lz;general;/Gentoo/usr/lib/libfontconfig.so;". When returning the absolute path both things work just fine. Thus for prefix the simplest way would be to return the absolute path in get_sandbox_lib() all the time, since there is no multilib in prefix anyway. That path could be set up nicely with the help of some configure argument. I guess spanky is able to come up with some nice guarded patch for that function ;-)
i really have no idea how the prefix toolchain wrappers work. if they go around inserting DT_RPATH tags where they arent expected (i.e. linking the sandbox binary), then the behavior you describe is most likely correct.
(In reply to comment #24) > i really have no idea how the prefix toolchain wrappers work. The wrapper around ld (from binutils-config, but not the wrapper from main tree) collects all the cmdline-given runpaths, filters out predefined prefix- and nonprefix-libdirs, re-adds them both at the end, and passes this list to the real linker for _each_ binary created. This way we do not need either ld.so.conf or LD_LIBRARY_PATH to let all the prefix binaries/libraries find their needed prefix libraries. > if they go > around inserting DT_RPATH tags where they arent expected (i.e. linking the > sandbox binary), When the sandbox binary is built using the prefix toolchain, it does have the prefix runpaths for sure. > then the behavior you describe is most likely correct. What is the reason to not put the full path for libsandbox into LD_PRELOAD?
i'd point at the comment already in the source code: /* Always let the dynamic loader do the searching rather than hard coding the * full path. This way, things like multilib, testing, local runs work easier. */
This does allow for finding different (or no at all) libs depending on the binary being exec'd. While this does help for multilib indeed, how does it help for testing and local runs? Problem is that in Prefix the runtime loader can be controlled via DT_RPATH/ DT_RUNPATH only. We do not regularly use LD_LIBRARY_PATH on purpose. What if placing libsandbox.so and its multilib variants into some otherways empty directory, use LD_PRELOAD without full path, and additionally have LD_LIBRARY_PATH and its different platform specific variants point to that directory? IIRC, some loaders try with appending their multilib dir to LD_LIBRARY_PATH first...
I applied heiko's hacky patch to sandbox-2.0 to unblock here, as bugs are piling up. It is not satisfactory, but I see no better option for the moment.
you could add a dlopen() test to sandbox and if it doesnt work, fall back to using the full path. although if sandbox itself is built with the right RPATH, it wont fail the dlopen() path.
does sandbox-2.5+ still have this problem ? there's logic in there now that conditionally sets the full path ... if not, what about always exporting LD_PRELOAD to "$(prefix)/$LIB/libsandbox.so" (i.e. expand $prefix, but hardcode a literal "$LIB" and let the ldso expand it) ?
Presuming gone given #c30 and no further reply.
