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