Ralf Wildenhues wrote:
> > Indeed, it would have to be documented in the user's documentation that
> > the relocatable module doesn't work on OpenBSD when shared libraries are
> > involved.
>
> Well. On systems where Libtool hardcodes an absolute soname. 1.5.22
> does it, and 1.5.24 will do it, but 2.0 will not do it any more on
> OpenBSD.
OK, I'm documenting it like this:
--- doc/relocatable.texi 1 Mar 2007 02:07:56 -0000 1.1
+++ doc/relocatable.texi 2 Mar 2007 01:24:51 -0000
@@ -33,7 +33,9 @@
Installation with @option{--enable-relocatable} will not work for
setuid or setgid executables, because such executables search only
-system library paths for security reasons.
+system library paths for security reasons. Also, installation with
[EMAIL PROTECTED] might not work not OpenBSD, when the
+package contains shared libraries and libtool versions 1.5.xx are used.
The runtime penalty and size penalty are negligible on GNU/Linux (just
one system call more when an executable is launched), and small on
> But there are some ancient or rarer systems where it will
> still happen.
These systems (Unixware etc.) are not worth mentioning today.
> > for example, --prefix=/tmp/inst$$.
>
> This bit doesn't. Since /tmp is usually world-writable, you've got your
> attack vector already.
/tmp is world-writable but a directory created by a user in /tmp is not
world-writable (assuming an umask of at least 002). Therefore I don't see
a security problem here.
Bruno
