Re: [PATCH][BZ #17250] Static dlopen default library search path fix

["Maciej W. Rozycki" <macro at linux-mips dot org>]

On Thu, 6 Aug 2015, Mike Frysinger wrote:

> > > >  I'm not prepared to properly regression-test a change right away, but 
> > > > meanwhile can you try the below as a proposed fix?  Also I'm not sure 
> > > > offhand how to make a test case that covers this issue, but I'll be happy 
> > > > to accept ideas and implement them.
> > > 
> > > two were posted to the bug.  if you use tests-static in the Makefile,
> > > should be fairly easy to add to the tree and check the result.
> > 
> >  Except that they cover the usual system-installed use case and we run our 
> > test suite over uninstalled libraries.  Normally that does not matter, but 
> > here it does.  Unless I'm missing something that is, am I?
> 
> the test requires:
>  - it be statically linked
>    -> use tests-static in the makefile
>  - the db accessed contains the data we request
>    -> nptl/tst-setuid1.c seems to already assume "nobody" is a valid acct
>  - it have access to the nss libs to load
>    -> set LD_LIBRARY_PATH to the local paths using the xxx-env hooks if
>       existing run logic doesn't already do it
> 
> what other external deps did you have in mind ?
> 
> i just tested it over here and it semed fine:
> $ gcc test.c -B. -static
> $ LD_LIBRARY_PATH=$PWD/nis:$PWD/nss:$PWD:$PWD/elf strace -e file ./a.out
> <all libs are loaded from $PWD>
> /etc/nsswitch.conf & /etc/passwd are read, but i think our tests already
> rely on that ...

 The bug affects any modules loaded dynamically from a static executable, 
so a dependency upon NSS having been configured in a particular way (mind 
the `--enable-static-nss' `configure' option) is not required.  An 
explicit test case triggering the problem is better than one indirectly 
relying on other subsystems anyway.  Such code can be easily written based 
on the nature of the problem.

 However according to both the bug report and how code affected looks like 
the problem only triggers for dynamic shared objects to be pulled from 
system directories, such as /lib or /usr/lib (assuming the usual system 
prefix), and I gather any further ones listed in /etc/ld.so.conf.  These 
are only populated at the install stage and therefore not relevant for 
regression testing.

 Furthermore the bug report explicitly refers to the setting of 
LD_LIBRARY_PATH as a workaround for the problem, so such an arrangement 
obviously cannot be used to trigger the bug.  So while code to trigger the 
problem can be easily made and run standalone, we currently have no 
provisions available to integrate it into our test suite.

 There was a discussion at the Glibc BOF at this year's GNU Tools Cauldron 
as to how to make the testing of libraries possible in cases where the 
root privilege or operation in a fully installed environment would 
normally be required to cover a problem being concerned, however at this 
point we are quite far from getting there I believe.

 Have I missed anything?

  Maciej