Re: relocatability tweaks

[Bruno Haible]

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