bug-gnulib
[Top][All Lists]
Advanced

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

Re: relocatability tweaks


From: Paolo Bonzini
Subject: Re: relocatability tweaks
Date: Mon, 17 Mar 2008 17:19:44 +0100
User-agent: Thunderbird 2.0.0.12 (Macintosh/20080213)


1) This choice should be an installer's choice, not a program developer's 
choice.
   Why? Often a package A depends on a package B which depends on a package C
   etc. In order to install package A relocatable, B and C must also be 
installed relocatable.
   But B and C most likely will not have relocatability enabled by default.

Not necessarily, though maybe I'm just not seeing the reason. As a developer, I could assume that dependent packages are installed with the distro package manager. For example, GNU Smalltalk can assume that iconv is not relocatable even though GNU Smalltalk provides bindings for it.

Or, one may like to have a relocatable package because on some machines he/she installs it in /usr/local, and on other in /opt/package-x.y.z -- in the latter case, in particular, it is important that a package does *not* know about other package's relocatability, because dependent packages will be installed under different prefixes (with LD_LIBRARY_PATH to allow finding the libraries).

2) Security considerations: The doc/relocatable.texi file mentions that for 
security reasons,
   when a relocatable installation is chosen, --prefix needs to be chosen in a 
particular way.
   With your patch, when gl_RELOCATABLE_DEFAULT is invoked, you have an insecure
   installation by default!

Yes, I read this in the documentation:

On some OSes the executables remember the location of shared libraries
and prefer them over any other search path

Is there a list of OSes with this property? Could we "test -d" the prefix and warn if it exists on these OSes?

However, if the programmer knows what he's doing, no shared libraries will be sought in $ORIGIN/../lib and actually the trampoline executable will not be needed (and there will be no security considerations to be careful about).

Did I miss something important, that is, am I looking for something that is similar to your idea of relocatability but "not quite it"?

Paolo




reply via email to

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