[Top][All Lists]

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

Re: first draft of "relocatable" module

From: Ralf Wildenhues
Subject: Re: first draft of "relocatable" module
Date: Thu, 22 Feb 2007 13:55:33 +0100
User-agent: Mutt/1.5.13 (2007-02-12)

Hello Ben, all,

* Ben Pfaff wrote on Thu, Feb 22, 2007 at 06:24:04AM CET:
> I've finished my first stab at a "relocatable" module for gnulib.

Just a couple of very quick comments:

> +Second, the loader must be able to find shared libraries linked to
> +relocatable executables or referenced by other shared libraries linked
> +to relocatable executables.  The @code{relocatable} module helps out
> +here in a platform-specific way:

when possible, that is.

> address@hidden
> address@hidden
> +On GNU/Linux, it adds a linker option (@option{-rpath}) that causes
> +the dynamic linker to search for libraries in a directory relative to
> +the location of the invoked executable.
> +
> address@hidden
> +On other Unix systems, it installs a wrapper executable.  The wrapper
> +sets the environment variable that controls shared library searching
> +(usually @env{LD_LIBRARY_PATH}) and then invokes the real executable.

The problem is here that this is not always possible.  There are two
failure scenarios (at least):

- A library was hardcoded with an absolute path, and you cannot override
  it at all  (e.g., DT_NEEDED contains /path/to/libfoo.so, which Libtool
  branch-1-5 does on OpenBSD; also I think OpenServer builds their stuff
  that way).
- A library was hardcoded with an absolute path, which you may or may
  not be able to override, but which still be searched.  This can happen
  as DT_NEEDED entry (e.g., on HP-UX/PA) or as DT_RPATH entry
  (most systems that have DT_RPATH).  This may or may not be considered
  a feature of your module, but I think it should be mentioned.
- The second possibility can have the variable take precedence (e.g.,
  Gentoo GNU/Linux, or Darwin), or the internal path (e.g., most
  GNU/Linux variants), or can be configured on a per-binary basis
  (e.g., HP-UX).  In the second or third cases, relocating an installed
  program just to install a different version (with possibly
  incompatible libraries) into the old location of the first may lead
  to trouble.

Each of these issues can have security implications, should the user not
be aware of them.

Hope that helps.


reply via email to

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