From owner-freebsd-hackers Sat Jan 6 10:23:07 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA07298 for hackers-outgoing; Sat, 6 Jan 1996 10:23:07 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA07286 for ; Sat, 6 Jan 1996 10:23:02 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id TAA14214 for ; Sat, 6 Jan 1996 19:22:59 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id TAA17813 for freebsd-hackers@freebsd.org; Sat, 6 Jan 1996 19:22:58 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.3/8.6.9) id TAA15371 for freebsd-hackers@freebsd.org; Sat, 6 Jan 1996 19:15:40 +0100 (MET) From: J Wunsch Message-Id: <199601061815.TAA15371@uriah.heep.sax.de> Subject: Re: Demand loading (Re: FreeBSD, Zappa & PCI) To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Sat, 6 Jan 1996 19:15:39 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199601061614.QAA14121@exalt.x.org> from "Kaleb S. KEITHLEY" at Jan 6, 96 11:14:50 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@freebsd.org Precedence: bulk As Kaleb S. KEITHLEY wrote: > > > > Who puts the RPATH into the executable? At least, simply linking it > > e.g. against an X11 library with ld doesn't put it there. > > When you have ELF, ld can put it there. It was ELF. I wrote about my troubles on a SystemV. (Unixware, actually. This machine has not yet been converted to FreeBSD, although the operator of the box would really like to have this happen. :) > Setuid *root* binaries ignore LD_LIBRARY_PATH, even with ELF. Does this imply that e.g. setgid kmem binaries under SysV do _not_ ignore LD_*_PATH, so i could abuse them? > > My only solution was to symlink the X cruft into /usr/lib. Not very > > exciting. > > This isn't necessary if you've ldconfig'd /usr/X11R6/lib into the > ld.so.cache? Yup, Unixware doesn't have an ld.so.cache. > > What about binaries where i want to shuffle the shared libs around > > later? > > Yuck. :-) With ELF it's reasonably easy to write a utility to rewrite > the RPATH in a program if you really wanted to move its libraries around. Ick. > > (E.g., they are linked against Motif, and i'd like to keep my > > copy of Motif in a separate subtree?) > > Keeping Motif (source?) in a separate subtree is one thing. You install > the libraries somewhere, right? /usr/X11R6/lib? You've added /usr/X11R6/lib > to your ld.so.cache, right? So with ELF, each application has it's own > ld.so.cache, except that it's called RPATH, and it's stored in each > application instead of the global /etc/ld.so.cache. So i have to parse my entire directory tree to find out all binaries that dynamically link the Motif lib? And i have to modify each of them manually? (I don't speak about things that will be recompiled from source, i think about a set of working binaries.) Btw., Lasermoon's ugly SWiM package did also use their own ld.so.cache in the mwm they're shipping: they have hard-linked it to /usr/X11R6/lib/libXm.so.2.0.0 -- even though they ship the system so that it installs into /usr/X386 (and i have forced the installation into /usr/Motif). You can imagine how i liked this. :-] > Other than the fact that ld.so.cache is a minor security hole. Okay, any > sysadmin worth their salt isn't going to add world writable directories > to the ld.so.cache, but you never know. Exactly. The ld.so.cache is intented to list a set of trustable libraries. (Btw., you are always implying that ld.so.cache would contain _directories_. This is not true. It lists every and all shared lib to be used.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)