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

[Kean Johnston]

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

Kean