On 2020-06-23 11:46, Ian Jackson wrote: > Aurelien Jarno writes ("Re: Bug#963508: /lib/ld-linux.so.2: LD_PRELOAD breaks > with plain filename"): > > 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. > > Hi. Thanks for your reply. apparmor may well be involved, and indeed > you are right to point out that the faketime repro is a red herring, > > But I think things are more complicated. > > Should apparmor make a difference between absolute paths and leafnames > in LD_PRELOAD ? Because I can reproduce that with eatmydata: > $ eatmydata env -u LD_LIBRARY_PATH > LD_PRELOAD='/usr/lib/x86_64-linux-gnu/libeatmydata.so' man ls >/dev/null > $ > > strace in the run with the error message shows it does successfully > open the intended .so file. But then it goes on to try lots of other > places instead and eventually prints that error message. It seems > that it opened the file but rejected it.
It's because running man involves running many binaries, and not all of them are run under apparmor. > I notice that during startup it does this > access("/etc/suid-debug", F_OK) = -1 ENOENT (No such file or > but none of my man-db binaries are setuid (I have double-checked). This is exactly my point. This happens because the binary is considered like a suid binary, ie the kernel sets AT_SECURE for binaries running with apparmor. From the glibc point of view, this disables, among other things, support for preloading. The glibc doesn't actually know the reason why AT_SECURE is enabled, historically it meant suid binaries (hence the suid-debug name), but nowadays, it's also used by selinux and apparmor. > I also notice that something in the invocation stack (presumably > something in man-db) is changing the LD_PRELOAD value from > LD_PRELOAD=libgtk3-nocsd.so.0 libeatmydata.so > to > LD_PRELOAD=libgtk3-nocsd.so.0:libeatmydata.so > and I didn't even know spaces were allowed! But this doesn't seem > relevant. > > If this were apparmor I would expect to see an EACCES or EPERM or > something. I searched the preconv strace for error reports and it > contains no E... other than (i) ENOENT (ii) this: > seccomp(SECCOMP_SET_MODE_STRICT, 1, NULL) = -1 EINVAL (Invalid argument) It's not apparmor preventing some syscall to be successful, but as said above, apparmor enabling the AT_SECURE mode for the binary. > > 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: > > You are right that all my discussion of faketime is a red herring, > because faketime's .so is not on the standard search path. > > > If a shared object dependency does not contain a slash, then it is > > searched for in the following order: > ... > > - 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. > > Did you c&p that text from a pre-multiarch document ? Evidently the > default search path does contain /usr/lib/x86_64-linux-gnu, which is > surely what is to be expected. And that is where the eatmydata .so is > located and indeed it opens it! I copied the man page, it indeed looks like out of date with regard to multiarch. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net