Bug#963508: /lib/ld-linux.so.2: LD_PRELOAD breaks with plain filename [and 1 more messages]

2020-06-24 Thread Florian Weimer
* Aurelien Jarno:

>> This doesn't seem correct to me.  Is there any documentation giving a
>> rationale for this ?  Is there a way to change this locally ?
>
> I do not know enough about apparmor and its threat model to know if it
> should be considered or not. From the glibc point of view, nothing can
> be really done, it just obeys the AT_SECURE flag passed by the kernel.
>
> Now looking at apparmor.d(5), it seems it *might* be controlled by the
> change_profile option with the safe and unsafe mode. But I don't speak
> apparmor fluently enough to actually know how to introduce that option
> in a profile.

I think LSMs can nowadays also express security transitions that trust
the execution environment, that is, that they add more restrictions
instead of increasing privileges.  I believe we use this with SELinux,
so that these transitions to do not cause AT_SECURE to be set.  Maybe
this is something that apparmor could do as well?

Thanks,
Florian



Bug#963508: /lib/ld-linux.so.2: LD_PRELOAD breaks with plain filename [and 1 more messages]

2020-06-23 Thread Aurelien Jarno
On 2020-06-23 14:17, Ian Jackson wrote:
> 
> Aurelien Jarno writes ("Re: Bug#963508: /lib/ld-linux.so.2: LD_PRELOAD breaks 
> with plain filename"):
> > [stuff]
> 
> Thanks for your explanations and sorry for being dense.
> 
> >   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).
> 
> Obviously it wouldn't be right for eatmydata to be loaded by actually
> setuid programs.
> 
> Ian Jackson writes ("Re: Bug#963508: /lib/ld-linux.so.2: LD_PRELOAD breaks 
> with plain filename"):
> > (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.)
> 
> So the overall effect is that programs with apparmor profiles are
> mostly protected from the effects of LD_PRELOAD (and, I assume,
> LD_LIBRARY_PATH and various other properties of the execution
> environment).

Yes, and also GCONV_PATH, GETCONF_DIR, HOSTALIASES, LOCALDOMAIN,
LOCPATH, MALLOC_TRACE, NIS_PATH, NLSPATH, RESOLV_HOST_CONF, RES_OPTIONS,
TMPDIR, and TZDIR.

> This doesn't seem correct to me.  Is there any documentation giving a
> rationale for this ?  Is there a way to change this locally ?

I do not know enough about apparmor and its threat model to know if it
should be considered or not. From the glibc point of view, nothing can
be really done, it just obeys the AT_SECURE flag passed by the kernel.

Now looking at apparmor.d(5), it seems it *might* be controlled by the
change_profile option with the safe and unsafe mode. But I don't speak
apparmor fluently enough to actually know how to introduce that option
in a profile.

> (Other than creating /etc/suid-debug, which is dangerous.)

Yes, this means that it becomes very easy to become root on a system
with that file.

Regards
Aurelien

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



Bug#963508: /lib/ld-linux.so.2: LD_PRELOAD breaks with plain filename [and 1 more messages]

2020-06-23 Thread Ian Jackson


Aurelien Jarno writes ("Re: Bug#963508: /lib/ld-linux.so.2: LD_PRELOAD breaks 
with plain filename"):
> [stuff]

Thanks for your explanations and sorry for being dense.

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

Obviously it wouldn't be right for eatmydata to be loaded by actually
setuid programs.

Ian Jackson writes ("Re: Bug#963508: /lib/ld-linux.so.2: LD_PRELOAD breaks with 
plain filename"):
> (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.)

So the overall effect is that programs with apparmor profiles are
mostly protected from the effects of LD_PRELOAD (and, I assume,
LD_LIBRARY_PATH and various other properties of the execution
environment).

This doesn't seem correct to me.  Is there any documentation giving a
rationale for this ?  Is there a way to change this locally ?
(Other than creating /etc/suid-debug, which is dangerous.)

Ian.



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

2020-06-23 Thread Aurelien Jarno
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



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

2020-06-23 Thread Ian Jackson
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 JacksonThese 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.



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

2020-06-23 Thread Aurelien Jarno
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 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



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

2020-06-23 Thread Colin Watson
On Tue, Jun 23, 2020 at 11:46:58AM +0100, 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.
[...]
> 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).

The name is a slight misnomer, presumably because it predates other
reasons why ld.so might be in secure-execution mode.

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

man-db never sets LD_PRELOAD.

> If this were apparmor I would expect to see an EACCES or EPERM or
> something.

I believe Aurelien's contention is not that AppArmor is denying the
request as such (which would indeed produce some kind of errno along
these lines), but rather that the fact that there's an AppArmor policy
defined for /usr/bin/man puts ld.so into secure-execution mode when
executing that binary.

> > > Colin Watson (CC'd) reports that sid works.
> > 
> > I have tested on sid and on experimental, I do not find a different
> > behaviour.

Apologies for the misdirection here: I was only testing in a sid chroot,
and hadn't considered the possible AppArmor issue.

In general, I don't regret my decision to add various confinement
tactics to man as a defence against possible vulnerabilities in the
rendering pipeline for manual pages.  However, it is clearly
inconvenient in the sort of case that Ian brings up.  I wonder if I need
to provide a separate utility for linting manual pages that doesn't
involve secure-execution mode in any way, in order that it can be used
by build systems without needing to worry about all this stuff.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]



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

2020-06-23 Thread Ian Jackson
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.

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

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)

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

And this works most of the time.  Just not in man.

(FTAOD I can't repro the eatmydata problem with dash.)

Ian.


[1] strace.  I did this:
  strace -ffot eatmydata env -u LD_LIBRARY_PATH man ls >/dev/null
This runs many processes but of these, the first to print the
error is `preconv':

  execve("/usr/bin/preconv", ["preconv", "-e", "UTF-8"], 0x55dc40160a50 /* 56 
vars */) = 0
  ...
  access("/etc/suid-debug", F_OK) = -1 ENOENT (No such file or
  directory)
  ...
  openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libeatmydata.so", O_RDONLY|O_CLOEXEC) 
= -1 ENOENT (No such file or directory)
  openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libeatmydata.so", 
O_RDONLY|O_CLOEXEC) = 5
  read(5, 
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\20\0\0\0\0\0\0"..., 832) = 
832
  fstat(5, {st_mode=S_IFREG|0644, st_size=14176, ...}) = 0
  close(5)= 0
  openat(AT_FDCWD, "/lib/tls/haswell/avx512_1/x86_64/libeatmydata.so", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
  [... loads more like this ...]
  writev(2, [{iov_base="ERROR: ld.so: object '", iov_len=22}, 
{iov_base="libeatmydata.so", iov_len=15}, {iov_base="' from ", iov_len=7}, 
{iov_base="LD_PRELOAD", iov_len=10}, {iov_base=" cannot be preloaded (", 
iov_len=22}, {iov_base="cannot open shared object file", iov_len=30}, 
{iov_base="): ignored.\n", iov_len=12}], 7) = 118


> > Experimenting shows that the problem is triggered by having LD_PRELOAD
> > containing only the library name:
> > 
> > $ faketime yesterday printenv | grep PREL
> > LD_PRELOAD=libgtk3-nocsd.so.0:/usr/$LIB/faketime/libfaketime.so.1
> > $ faketime yesterday env LD_PRELOAD=libfaketime.so.1 man ls >/dev/null 
> > ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded 
> > (cannot open shared object file): ignored.
> > ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded 
> > (cannot open shared object file): ignored.
> > ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be prelo

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

2020-06-22 Thread Aurelien Jarno
On 2020-06-22 19:00, Ian Jackson wrote:
> Package: libc6
> Version: 2.28-10
> Severity: normal
> File: /lib/ld-linux.so.2
> 
> Hi.  I found this behaviour:
> 
> $ eatmydata man ls >/dev/null 
> ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded 
> (cannot open shared object file): ignored.
> ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded 
> (cannot open shared object file): ignored.
> ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded 
> (cannot open shared object file): ignored.
> ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded 
> (cannot open shared object file): ignored.
> $

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.

> Experimenting shows that the problem is triggered by having LD_PRELOAD
> containing only the library name:
> 
> $ faketime yesterday printenv | grep PREL
> LD_PRELOAD=libgtk3-nocsd.so.0:/usr/$LIB/faketime/libfaketime.so.1
> $ faketime yesterday env LD_PRELOAD=libfaketime.so.1 man ls >/dev/null 
> ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded 
> (cannot open shared object file): ignored.
> ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded 
> (cannot open shared object file): ignored.
> ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded 
> (cannot open shared object file): ignored.
> ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded 
> (cannot open shared object file): ignored.
> ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded 
> (cannot open shared object file): ignored.
> ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded 
> (cannot open shared object file): ignored.
> ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded 
> (cannot open shared object file): ignored.
> ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded 
> (cannot open shared object file): ignored.
> $

faketime.so.1 is not in the standard path, ie on an amd64 system not
directly in /usr/lib/x86_64-linux-gnu:

$ dpkg -L libfaketime | grep libfaketime.so.1
/usr/lib/x86_64-linux-gnu/faketime/libfaketime.so.1

So you definitely need to use the full path, or add that path to
LD_LIBRARY_PATH or to /etc/ld.so.conf.

> The problem is not limited to man:
> 
> $ faketime yesterday env LD_PRELOAD=libfaketime.so.1 dash -c true
> ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded 
> (cannot open shared object file): ignored.
> $

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:

If a shared object dependency does not contain a slash, then it is
searched for in the following order:

- Using the directories specified in the DT_RPATH dynamic section
  attribute of the binary if present and DT_RUNPATH attribute does not
  exist. Use of DT_RPATH is deprecated.

- Using the environment variable LD_LIBRARY_PATH, unless the executable
  is being run in secure-execution mode (see below), in which case this
  variable is ignored.

- Using the directories specified in the DT_RUNPATH dynamic section
  attribute of the binary if present. Such directories are searched only
  to find those objects required by DT_NEEDED (direct dependencies)
  entries and do not apply to those objects' children, which must
  themselves have their own DT_RUNPATH entries. This is unlike DT_RPATH,
  which is applied to searches for all children in the dependency tree.

- From the cache file /etc/ld.so.cache, which contains a compiled list
  of candidate shared objects previously found in the augmented library
  path. If, however, the binary was linked with the -z nodeflib linker
  option, shared objects in the default paths are skipped. Shared
  objects installed in hardware capability directories (see below) are
  preferred to other shared objects.

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

> This message on debian-user seems related:
>   https://lists.debian.org/debian-user/2017/03/msg00335.html

Yes, there seems to be an issue there, but I am personally not able to
reproduce it. Note however that I only tried it in a jessie chroot, not
in a complete jessie system.

> Colin Watson (CC'd) reports that sid works.

I have tested on sid and on experimental, I do not find a different
behaviour.

Regards,
Aurelien

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



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

2020-06-22 Thread Ian Jackson
Package: libc6
Version: 2.28-10
Severity: normal
File: /lib/ld-linux.so.2

Hi.  I found this behaviour:

$ eatmydata man ls >/dev/null 
ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.
ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.
ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.
ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.
$

Experimenting shows that the problem is triggered by having LD_PRELOAD
containing only the library name:

$ faketime yesterday printenv | grep PREL
LD_PRELOAD=libgtk3-nocsd.so.0:/usr/$LIB/faketime/libfaketime.so.1
$ faketime yesterday env LD_PRELOAD=libfaketime.so.1 man ls >/dev/null 
ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.
ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.
ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.
ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.
ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.
ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.
ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.
ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.
$

The problem is not limited to man:

$ faketime yesterday env LD_PRELOAD=libfaketime.so.1 dash -c true
ERROR: ld.so: object 'libfaketime.so.1' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.
$

This message on debian-user seems related:
  https://lists.debian.org/debian-user/2017/03/msg00335.html

Colin Watson (CC'd) reports that sid works.

Thanks for your attention.

Ian.

-- System Information:
Debian Release: 10.4
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages libc6:i386 depends on:
ii  libgcc1  1:8.3.0-6

Versions of packages libc6:i386 recommends:
ii  libidn2-0  2.0.5-1+deb10u1

Versions of packages libc6:i386 suggests:
ii  debconf [debconf-2.0]  1.5.71
ii  glibc-doc  2.28-10
ii  libc-l10n  2.28-10
ii  locales2.28-10

-- debconf information excluded