When turning on FEATURES=sandbox on RAP system, the emerge process succeeded but with many lines of warning: ERROR: ld.so: object 'libsandbox.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. It turns out that at least one of the reason is the unprefixied shebang, especially '/usr/bin/env', is used. I'l attach the build.log of sys-apps/baselayout-2.15::gentoo as an example. Reproducible: Always
Created attachment 887879 [details] build.log for sys-apps/baselayout-2.15::gentoo
Created attachment 887880 [details] emerge --info
> It turns out that at least one of the reason is the unprefixied shebang, especially '/usr/bin/env', is used. What lead you to this conclusion?
(In reply to Mike Gilbert from comment #3) > > It turns out that at least one of the reason is the unprefixied shebang, especially '/usr/bin/env', is used. > > What lead you to this conclusion? I execute ebuild --debug baselayout-2.15.ebuild clean merge, and locate the commands where such error messages jump out, like: + find . -mindepth 1 -maxdepth 1 '!' -type l -print0 + xargs -r -0 /opt/gentoo/usr/lib/portage/python3.12/chmod-lite ERROR: ld.so: object 'libsandbox.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. chmod-lite has the shebang #!/usr/bin/env bash Then I made a MWE /tmp/test.sh ```bash #!/usr/bin/env bash echo hello ``` LD_PRELOAD=libsandbox.so /tmp/test.sh gives ERROR: ld.so: object 'libsandbox.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. hello while using #!/opt/gentoo/usr/bin/env bash shebang does not have such error msg. Replacing such shebangs of all portage scripts eliminates most of the error msgs during emerge, but some still persists: + declare -F post_pkg_setup + (( __EBEGIN_EEND_COUNT > 0 )) + set +x ERROR: ld.so: object 'libsandbox.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object 'libsandbox.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. + true which I still can't understand
Ah, I see. /usr/bin/env would not have RPATH applied to it and would try to load libsandbox.so from the host system libdirs. Yeah, I think we will need to revisit how we deal with shebangs when installing Portage if we actually want to support sandbox on RAP.
Created attachment 889487 [details, diff] patch for portage to prefixify all shebang in qa check
(In reply to Yiyang Wu from comment #6) > Created attachment 889487 [details, diff] [details, diff] > patch for portage to prefixify all shebang in qa check I tried this patch to portage and bootstrap a prefix. I observe 3 issues: 1. Stage1 portage shouldn't prefixify "/usr/bin/env" because the coreutils inside prefix is not installed yet. So I installed the unpatched portage for stage 1. 2. At stage2, python fails to emerge because upstream ship cgi.py with "/usr/local/bin/python" as shebang, thus triggering invalid shebang QA error. Currently Debian sid and Fedora[1] fix this shebang, but Gentoo does not. I think this is a dev-lang/python issue. 3. In stage3, many packages like dev-lang/perl are installed before sys-apps/portage, so it is using the unpatched portage that does not prefixify their shebangs. And for some reason these package does not rebuild, and ends up in the final Gentoo prefix. I believe issue 1 and 3 can be resolved by determine whether portage is running in stage 1 and 2, and choose not to prefixify too much in stage 1/2. [1] https://src.fedoraproject.org/rpms/python3.11/blob/rawhide/f/python3.11.spec#_938
I'd like to consult Fabian, the creator of shebang prefixify mechanism, that what blocked us to prefixify shebang of all scripts, and just fix those in ${PATH} (and also openrc init scripts). For example, (In reply to Fabian Groffen from comment https://bugs.gentoo.org/282539#c4) > ok, I implemented a warnlist and whitelist. /usr/bin/env is on the > whitelist (note: /bin/env is not valid: it doesn't exist on many systems!), > while /bin/sh is on the warnlist. Reason is that some scripts assume > /bin/sh to be POSIX sh, which is a wrong assumption for most of our systems. However, I fail to see the reason why "/usr/bin/env" is in the whitelist. (In reply to Fabian Groffen from comment https://bugs.gentoo.org/282539#c11) > I just changed the code to only scan executable files. This should reduce > the number of "fixed" and offending files drastically, limiting to only what > really matters So basically we were afraid prefixifing all shebangs are too aggressive. Now it is noticed that many scripts not in ${PATH} are actually executed. E.g. during emerge, /usr/bin/env is called many times that triggers "ERROR: ld.so: object 'libsandbox.so' from LD_PRELOAD cannot be preloaded". So shall we re-investigate about prefixifying all shebangs?
if you don't have env in your EPREFIX, your entire script doesn't work even though it could without any drawbacks the /usr/bin/env provided by the host just looks up the argument in PATH, which includes EPREFIX if all is well, and thus ends up with e.g. bash from your EPREFIX, or if it isn't there (yet) with a bash from the host or a tmp location, such as when you bootstrap a Prefix install. It also doesn't require any fixing or modifications. It is static, and works for Prefix and non-Prefix the same. Why would /usr/bin/env cause LD_PRELOAD problems? Because RAP needs the runtime linker to see the correct library paths? If that's the case we need to see whether perhaps some rpath injections need to be made in RAP like we do in non-RAP, where this issue is not happening.
(In reply to Fabian Groffen from comment #9) > Why would /usr/bin/env cause LD_PRELOAD problems? /usr/bin/env is going to run the host's runtime linker. Assuming the host system is not Gentoo, libsandbox.so is unlikely to be installed on the host. libsandbox.so would exist within prefix, but the host's runtime linker isn't going to look there. That would be a bad idea anyway since it would likely lead to conflicting libraries getting loaded for host system binaries.
Indeed, as I indicated this is a RAP-specific problem. I think it should be ok for RAP to use its own env, we just need to make provisions during bootstrap.
(In reply to Fabian Groffen from comment #11) > Indeed, as I indicated this is a RAP-specific problem. > > I think it should be ok for RAP to use its own env, we just need to make > provisions during bootstrap. Yes, indeed. For non RAP system we use host linker and do have such problem. Actually the LD_PRELOAD problem of /usr/bin/env is a small issue -- just output annoying warnings with sandbox, and sandbox is still applied on processes using RAP's linker. Not having sandbox on /usr/bin/env should be harmless, I guess. However, I also noticed that many scripts not in ${PATH} have unprefixed (or even non-existing) shebangs, and may get executed, like cgi.py in dev-lang/python. That make me think if we should apply shebang check and fix for all executable files, not only the one in ${PATH} and init script. And validate the existence of shebang in QA check may not be limited to prefix system.
Checking/fixing all files should be tried because the check will die if it doesn't find the shebang target. I fear it may break here and there, because not all files are actually used, or are meant as examples. You could fix them, but not check them, or something. Anyway, that would lead to a more interesting thing where we'd split the checking of the shebang out to a separate QA check, that we could also run for non-Prefix. Because in a way, it makes no sense to distribute scripts with shebangs that will never work because the program they require doesn't exist.
