Paolo Bonzini wrote: > Did I miss something important, that is, am I looking for something that > is similar to your idea of relocatability but "not quite it"?
If you have read doc/relocatable.texi and doc/relocatable-maint.texi, you should have the same understanding of it as I do. > 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. That is actually a decision of the package provider, not of the programmer. For example, some people are distributing binaries of VLC, Blender, or similar high-value programs with all dependent libraries included. If they distribute libiconv with their program, it will be relocatable with the same prefix as their program. > 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). Yes, exactly. It is the package provider which decides whether he wants a packages and/or its dependent packages to be relocatable. > > 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? I think this is all platforms except Linux and mingw. > Could we "test -d" the prefix and warn if it exists on these OSes? I don't think it would be a good approach to security to compile binaries with a security hole by default, and just warn about them. Only a small minority of package installers are looking at warnings. It is our duty to produce the minimum possible number of CERT alerts. This means, we need to drive around security landmines at a large enough distance. > 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). What do you mean here by "if the programmer knows what he's doing"? Do you mean, the programmer has a different mechanism for ensuring relocatability, that does not use the runtime loader for shared libraries? How should that different mechanism look like? Bruno
