On 2020-06-23 12:21, Ian Jackson wrote: > 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.
Yes, this indeed matches the glibc code. In practice they are cases were preloading is still accepted for secure-execution, if the shared library is suid. Here is the excerpt from the manpage: In secure-execution mode, preload pathnames containing slashes are ignored. Furthermore, shared objects are preloaded only from the standard search directories and only if they have set-user-ID mode bit enabled (which is not typical). So the file is opened, and fxstat is used with the resulting fd to fetch its mode. I guess this is done that way to avoid any race condition, to make sure that the shared library being read is the same that the one being tested with fxstat. > > > 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.) Again this matches the glibc code. As said in the documentation, in secure-mode paths that contain slashes are simply discarded. In short the libeatmydata.so is not used, something that you can confirm using strace. > 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 ? Because libgtk3-nocsd.so.0 from the debian package is shipped with suid root. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net