Re: PATCH: ldconfig.c considers ld.so.conf entries before /lib,/usr/lib

[Camm Maguire <camm at enhanced dot com>]

Greetings, and thanks to all for their contributions to this
discussion.  I'm maintaining atlas for Debian, so I thought I'd try to
clarify why I also think that the traditional ldconfig behavior is
very important to applications of this sort.

There are many ways to look at it, but the most immediate is this: the
(currently) most popular architecture (x86) has four, mostly
incompatible sets of cpu extension instructions, sse1, sse2, 3dnow1
and 3dnow2.  On the ppc, there is an altivec extension; on sparc,
sparc64 behaves as an extension, and on alpha, ev5 and higher is an
extension to ev4. 

While gcc does not yet produce assembler for most (maybe all) of these
extensions, code is being written, by hand and by generator, to use
the new instructions in widely used/distributed applications.  atlas
is one, gmp is another.  As for the blas libs provided by atlas, these
are the foundation of a *very* large pillar of numerical code used in
scientific computation -- lapack, scalapack/pblas, R, octave, etc.  In
this case in particular, it is not only important to provide the
fastest blas possible, but to *facilitate work-arounds for
mistakes/errors* as they are discovered.  By having reference
and optimized blas libs simultaneously available in shared lib form, a
*user* can switch between them at runtime without recompilation if the
particular problem she is working on appears suspicious, or simply
fails.  In addition, in the case of a cluster mounting /usr via nfs,
one would like each client to be able to run the best version for the
current client cpu.  When a cpu, or in some cases a kernel, is
upgraded, it is a trivial task to add a line in /etc/ld.so.conf, run
ldconfig, and the *all* programs on the system default to the best
available libraries -- this could even be put into a boot time script.

This really is no news, as it reflects the same basic philosophy
behind current glibc practice of searching mmx and ix86 (and
combinations) subdirectories.  The only problem is that the current
scheme does not admit sufficient resolution, and to add
sse1,sse2,3dnow1,3dnow2 dirs to the mmx/ix86 list (just for starters)
might justifiably be seen as getting out of hand.  So the ability for
the administrator to *simulate the same behavior* for the cpu
capabilities at her disposal via /etc/ld.so.conf appears crucial.

This is in addition, of course, to the scenarios where an
administrator would prefer not to manually override files in /usr/lib
maintained by the packaging system, but to nevertheless work around to
library error by placing a fixed version in a dir higher up in the
cache, especially if this is a testing arrangement on a single client
in an nfs mounted /usr cluster.

Some other points, as they have been raised:

1) The current version of ldconfig is the standard, and cannot be
   changed as it might break something.  As stated by another poster,
   I can assure you that it is the new version of ldconfig which
   *will* break our existing systems if and when the libc is
   upgraded, and this is in an investment company managing billions of
   dollars of equities for institutional clients.  I've been using
   Linux since 1994, and ldconfig to my knowledge has operated in the
   traditional way without problems during this whole period.  I'd
   wager other unices behave similarly.

2) ldso does not load setuid libs from cache directories, and it would
   be preferable to have the same libs loaded whether running setuid
   or not.  I am no security expert, but it appears to me that if you
   can write to /etc/ld.so.conf, you can write to /lib and /usr/lib,
   so the gain in security could really only be said to stem from
   preventing administrator mistakes, like loading a world-writable
   directory into the cache.  Might I suggest two possible
   resolutions: 

	a) ldso will not load suid libs from any dir, standard or in
   the cache, which is writable by anyone other than root, nor any
   lib which is itself writable by anyone other than root.  This is
   more comprehensive than the current scheme, and catches more such
   potential administrator errors.   Additionally, as I assume that
   the currently searched subdirs mmx/ix86 are treated the same as
   /usr/lib and /lib in this regard, this proposal renders less
   arbitrary the different treatment of two ostensibly equivalent
   subdirs of /usr, namely local/ and mmx/... . Should we really
   distinguish between these subdirs by name alone?  Of course, ldso
   may already check the dir/lib permissions in the hardwired paths --
   if so, wouldn't extending this policy to dirs in the cache cover
   the security issue?

	b) Allow for the possibility that different libs will be
   loaded when running setuid.  What's the matter with this?  With the
   current setup, if you have identically named libs in two different
   directories in the cache, a user can load either one, albeit not
   setuid.  But the fact remains that a user can choose alternate
   versions of installed libs when not running setuid.  Why is this
   any different than allowing the administrator to designate a
   default lib in a non-standard dir which will take effect in the
   non-setuid case?  Just as in the former case a user can toggle libs
   with LD_LIBRARY_PATH, so in the latter can she toggle by choosing
   to run a program setuid or not.  This has no security implications,
   but apparently there is some desire that the same libs get loaded
   under different circumstances, and my only point is that the
   current setup already allows different libs to be loaded in
   different circumstances, and some times very 'silently', as in a
   forgotten LD_PRELOAD in the environment, etc.  One can always check
   which libs one is getting with ldd.

Thanks again to all for their work on these programs!



-- 
Camm Maguire			     			camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah