On 2020-06-22 19:00, Ian Jackson wrote: > Package: libc6 > Version: 2.28-10 > Severity: normal > File: /lib/ld-linux.so.2 > > Hi. I found this behaviour: > > $ eatmydata man ls >/dev/null > ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded > (cannot open shared object file): ignored. > ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded > (cannot open shared object file): ignored. > ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded > (cannot open shared object file): ignored. > ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded > (cannot open shared object file): ignored. > $
You probably have apparmor installed and enabled on your system. Binaries that are run with an apparmor profile get AT_SECURE enabled, which disables many features that have an impact on security, including preloading libraries. > Experimenting shows that the problem is triggered by having LD_PRELOAD > containing only the library name: > > $ faketime yesterday printenv | grep PREL > LD_PRELOAD=libgtk3-nocsd.so.0:/usr/$LIB/faketime/libfaketime.so.1 > $ faketime yesterday env LD_PRELOAD=libfaketime.so.1 man ls >/dev/null > ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded > (cannot open shared object file): ignored. > ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded > (cannot open shared object file): ignored. > ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded > (cannot open shared object file): ignored. > ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded > (cannot open shared object file): ignored. > ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded > (cannot open shared object file): ignored. > ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded > (cannot open shared object file): ignored. > ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded > (cannot open shared object file): ignored. > ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded > (cannot open shared object file): ignored. > $ faketime.so.1 is not in the standard path, ie on an amd64 system not directly in /usr/lib/x86_64-linux-gnu: $ dpkg -L libfaketime | grep libfaketime.so.1 /usr/lib/x86_64-linux-gnu/faketime/libfaketime.so.1 So you definitely need to use the full path, or add that path to LD_LIBRARY_PATH or to /etc/ld.so.conf. > The problem is not limited to man: > > $ faketime yesterday env LD_PRELOAD=libfaketime.so.1 dash -c true > ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded > (cannot open shared object file): ignored. > $ Same issue here, you can't just assume that /lib/ld-linux.so.2 will search on the full filesystem. Here are the paths that are searched according to the man page: If a shared object dependency does not contain a slash, then it is searched for in the following order: - Using the directories specified in the DT_RPATH dynamic section attribute of the binary if present and DT_RUNPATH attribute does not exist. Use of DT_RPATH is deprecated. - Using the environment variable LD_LIBRARY_PATH, unless the executable is being run in secure-execution mode (see below), in which case this variable is ignored. - Using the directories specified in the DT_RUNPATH dynamic section attribute of the binary if present. Such directories are searched only to find those objects required by DT_NEEDED (direct dependencies) entries and do not apply to those objects' children, which must themselves have their own DT_RUNPATH entries. This is unlike DT_RPATH, which is applied to searches for all children in the dependency tree. - From the cache file /etc/ld.so.cache, which contains a compiled list of candidate shared objects previously found in the augmented library path. If, however, the binary was linked with the -z nodeflib linker option, shared objects in the default paths are skipped. Shared objects installed in hardware capability directories (see below) are preferred to other shared objects. - In the default path /lib, and then /usr/lib. (On some 64-bit architectures, the default paths for 64-bit shared objects are /lib64, and then /usr/lib64.) If the binary was linked with the -z nodeflib linker option, this step is skipped. > This message on debian-user seems related: > https://lists.debian.org/debian-user/2017/03/msg00335.html Yes, there seems to be an issue there, but I am personally not able to reproduce it. Note however that I only tried it in a jessie chroot, not in a complete jessie system. > Colin Watson (CC'd) reports that sid works. I have tested on sid and on experimental, I do not find a different behaviour. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net