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[1] 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

> 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


Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurel...@aurel32.net                 http://www.aurel32.net

Reply via email to