libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why is "setting LD_LIBRARY_PATH very bad"?


From: Brian Dessent
Subject: Re: Why is "setting LD_LIBRARY_PATH very bad"?
Date: Wed, 24 Oct 2007 16:41:35 -0700

Wintaki Hagabashi wrote:

> - Perhaps it is possible to create a replacement library that some
> suid application uses and you can then gain root access (maybe there
> are other things stopping this from happening?)

On linux at least, LD_LIBRARY_PATH is ignored when invoking something
that has the setuid or setgid bit.

> - Big pain when developing, have to make sure your LD_LIBRARY_PATH is
> always set correctly, pointing to your build area.  And then if you
> have multiple checkouts (perhaps working on a branch), you need to
> keep changing your LD_LIBRARY_PATH.

But this is the libtool list, and the above is exactly the kind of
tedium that libtool takes care of for you so that you don't have to
worry about it.

> Having said that, I don't see what the problem is really in a
> controlled environment with production installations?  Again, using my
> Oracle example, there is no way they could force you to install into a
> special place.  They require setting LD_LIBRARY_PATH.  Obviously you
> don't want every single utility and application installed having its
> own special lib dir, but isn't that the normal thing to do for
> large(r) software distributions?  Especially commercial software?
> 
> And what is a real problem is when you do need to move a package.
> THen the rpath can cause a big headache for you depending on the
> situation.

If you ask me, these binary packages should either:

A. Play nice with the existing package management system of the
   distro by shipping in a .deb/.rpm/whatever package that:
     - installs to the system locations like /usr/lib, /usr/bin,
       /usr/share, etc.
     - allows clean install/uninstall/upgrade/remove using the
       familiar package manager commands
     - captures the library dependencies of the software so that
       all required support items of the required versions are
       also automatically installed
     - prevents accidents like the user running routine security
       updates from the distro which installs an incompatible
       version of some lib because the binary software's
       requirements were not communicated to the package
       management system

(i.e. the general principle of: don't mess around behind the back of the
package management system, it's there to help you, not something that
gets in the way.)

or

B. Ship with an install script that updates /etc/ld.so.conf to add
   the required paths.

Brian




reply via email to

[Prev in Thread] Current Thread [Next in Thread]