This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


On Thu, Aug 30, 2001 at 05:05:40PM +0200, Andreas Jaeger wrote:
> Ben Collins <bcollins@debian.org> writes:
> 
> > On Wed, Aug 29, 2001 at 08:34:34PM -0700, Ulrich Drepper wrote:
> > > Dirk Eddelbuettel <edd@debian.org> writes:
> >> 
> >> > ldconfig -v [from Debian's libc6_2.2.4-1 package] reads /lib and /usr/lib
> >> > before it considers the directories in /etc/ld.so.conf.  This is in conflict
> >> > with ld.so(8) as well as ldconfig(8).
> >> 
> >> It's completely irrelevant what the man pages say.  If they are not in
> >> line with the implementation it's the implementation setting the
> >> standard.
> >> 
> >> The current way ldconfig works is how it worked ever since.  There is
> >> no reason to change it since this will have negative effects and might
> >> suddenly change the behavior of people's systems.
> >
> > Not entirely true. From the original ldconfig.c in the ld.so sources:
> 
> Please note that the ldconfig implementation in glibc is a clean
> implementation.  Due to copyright concerns we couldn't take the so
> called "original" ldconfig and I couldn't look up how exactly ldconfig
> worked in some details.

That's fine, but the implementation details should still be compatible
(which obviously they seem to be, except for this point).

> IMO there's also a usability aspect to this:
> 
> If you do not use ldconfig, glibc searches per default only /lib and
> /usr/lib.  Those are the normal paths.

That still holds, even with the patch.

> For setuid applications, the pathes /lib and /usr/lib are also special
> since glibc will not lookup any libs in the cache.  Putting /lib and
> /usr/lib first will give the same libraries independ whether you're
> running setuid or not.

Since only root should be editing /etc/ld.so.conf, then I don't see the
security implications. It may be the administrator's choice to put some
replacement libraries in /usr/local/lib, and add that to
/etc/ld.so.conf, and expect them to override the libraries managed by
the package tools in /lib and /usr/lib. Without this ability, then the
administrator has to perform a circus act to get their libraries to
work, without the package manager crapping everything up. So this patch
has other benefits not possible with the current implementation.

> Why can't you put the libs into /usr/lib ?  What kind of problem do
> you have that you need to install the libs twice in the system and
> additionally need to edit /etc/ld.so.conf and then run ldconfig?

>From my understanding in this case, the ones in /usr/lib/ are generic
compiled, and from a different source. The special libraries installed
are optimized from another source, and do not work on all CPU's. Since
the optimized libs only override certain parts of the package that
supplies the main library (i.e. only runtime changes, and not linkable
objects, and not binaries), the packages have to live together, and not
overwrite each other.

-- 
 .----------=======-=-======-=========-----------=====------------=-=-----.
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  bcollins@debian.org  --  bcollins@openldap.org  --  bcollins@linux.com  '
 `---=========------=======-------------=-=-----=-===-======-------=--=---'


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]