Bug#963508: /lib/ld-linux.so.2: LD_PRELOAD breaks with plain filename

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Aurelien Jarno writes ("Re: Bug#963508: /lib/ld-linux.so.2: LD_PRELOAD breaks with plain filename"):
> On 2020-06-23 11:46, Ian Jackson wrote:
> > 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 don't think that can be the whole explanation.

The strace rune I used gives a different output file for each
process.  The process which prints the error message is the same one
which previously successfully opens the file - see my strace output,
which is just from man's run of preconv.

> > 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.

Thanks, yes, that does seem to be the case.

I searched my strace outputs again and the processes that print the
error message are precisely the same processes that call access on
/etc/suid-debug.  And I did find /etc/apparmor.d/usr.bin.man which
does talk about preconv (for example).

However ...

> 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 think more must be going on.

If it were merely that support for preloading was disabled, why does
it even try to search for the library ?

Why does providing an absolute path make it quiet ?  (I haven't been
able to find an easy way to see whether the LD_PRELOAD is being
honoured.)

Why does my ambient LD_PRELOAD of libgtk3-nocsd.so.0 (which applies to
all programs in my session) not produce the same error message ?

(As an aside, I'm not sure why it makes sense for apparmor to inhibit
preloading.  I thought apparmor was intended to restrict the
applications you apply it to, not defend them against their callers.)

Thanks for your attention.

Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.