Re: SCO/bugfix patch 7 of 10: Improve SCO platform support

[Ralf Wildenhues]

Hi Kean,

* Kean Johnston wrote on Wed, Nov 09, 2005 at 10:26:11AM CET:
> >I believe hardcode_libdir_flag_spec should be set to 
> >  '${wl}-R,$libdir'
> >in any case.  This has little to do with absolute sonames, but with the
> >dependent programs finding the library.  So the SCOABSPATH hack is
> >mixing up different issues here.
> Not at all. If you are using absolute path names you have absolutely
> no need to have a DT_RUNPATH entry in the executable, and in fact,
> having one there can change the runtime semantics of the program
> becuase the search order for libraries will be subtly different

D'oh, I read the logic the wrong way round (i.e., I thought you added
the -R$libdir only when SCOABSPATH was set, not when it was unset).
Sorry for that confusion.

> (for any shared libraries that do *not* have absolute path names
> becuase they were constructed before the libtool patch). That has
> forseeable, albeit unlikely, security implications. Here's why.
> 
> Suppose, for arguments sake, you had an a.out with a DT_RUNPATH
> entry pointing to /usr/pgsql/lib. That a.out is has the following
> DT_NEEDED entries:
>    /usr/lib/libc.so.1
>    /usr/pgsql/lib/libpq.so.8
>    libz.so.1
> 
> The /usr/pgsql directory is owned by the PostgreSQL db admin, who
> in BigCorp, isn't root, just a DBA. All that DBA needs to do to
> get root on that machine is put in a libz.so.1 in /usr/pgsql/lib
> and wait for root to run a postgres command at voila, they have
> root access.
> 
> Without the DT_RUNPATH entry, the RTLD will use the normal
> LD_LIBRARY_PATH and standard system locations, which we can assume
> a competant root will protect himself from.

Ah, ok.  Hmm, this means though that we /may/ need to refine my
absolute-soname proposal.

- When linking against a library that has an absolute soname, we should
  not add its path to rpath.  This probably requires that the installed
  library has a .la file present, and the absolute path setting is
  recorded there, so we can know about this fact.

Now what I don't know is: Do we also need to parameterize this question?
IOW: if an absolute soname overrides whatever other paths are used for
searching, then we wouldn't have to take care of this step.  OTOH, if it
could not be overridden at all at link time (as opposed to at execution
time), that would prevent DESTDIR setups, which would suck. :-/
(I don't know if such a system exists.)

With your current SCOABSPATH hack, the information would not be present
in the installed .la files, so when you finally upgrade to a working
-absolute-soname libtool, you will still have to install everything
again, or we'd have to add yet another (really gross, and
system-dependent) hack to find out whether the soname of the installed
library is absolute.  Right?  The change of hardcode_libdir_flag_spec
depends not on whether your currently compiled library will have
absolute soname, but whether your installations of its dependencies had
it.

Other than above thoughts: your scenario _is_ pretty artificial, don't
you think?  I mean, if you either don't trust your PostgreSQL db admin,
or if you have a root admin that executes postgres commands (or any
commands at all, FWIW) without thinking, you have bigger problems than
worrying about shared library searching?!  I mean, he could just add
malicious code right in libpq anyway, no need for any shared library
search order games?  ;)
(But you do have a point anyway: you might want to guard against him
inadvertantly installing a different libz there.)

Cheers,
Ralf