Re: setuid binaries lose their LD_RUN_PATH settings when LD_LIBRARY_P ATH is set

[Andreas Jaeger]

Justin Hahn <address@hidden> writes:

> The below is occurring in a current debian unstable (my workstation) with
> glibc 2.2.3 - I don't know when it started occurrring.
>
> Currently I'm using a couple PAM modules that link against libraries not in
> the standard paths (this is intentionaly). If I set LD_RUN_PATH at compile
> time this (of course) works splendidly. Further if I set LD_LIBRARY_PATH to
> include the LD_RUN_PATH dirs things work fine UNLESS the binary is setuid.
>
> In the case of a setuid binary, the LD_RUN_PATH is ONLY honored if the
> LD_LIBRARY_PATH doesn't include it.

> This doesn't appear limited in any way to just PAM modules, and in fact you
> can even build your own trivial example at will.
>
> Example:
> 1. LD_RUN_PATH=/usr/local/lib 
> 2. ssh links against libcrypto located in /usr/local/lib and is setuid root.
> 3. LD_LIBRARY_PATH=/usr/local/lib:/opt/foo:....
>
> Result: libcrypto.so isn't found.
>
> HOWEVER, removing /usr/local/lib from LD_LIBRARY_PATH magically restores
> functionality.
>
> My interim solution is to build everything with LD_RUN_PATH, but that isn't
> always feasible (esp. with closed source products!) 
>
> My only guess is that when the runtime linker reduces the search path it
> chops all of LD_LIBRARY_PATH out after adding anything from LD_RUN_PATH. The
> order should probably be reversed. I haven't looked at the relevant code so
> I'm uncertain as to what precisely you are doing, but that's what it seems
> like.

LD_LIBRARY_PATH is dropped for setuid applications out of security
reasons.

But you - as system admin - can add the dir to /etc/ld.so.conf and
rerun ldconfig.  That way you don't need to set LD_LIBRARY_PATH at
all.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs address@hidden
   private address@hidden
    http://www.suse.de/~aj