Re: dpkg-shlibdeps and private libraries
On Sat, Nov 17, 2007 at 04:24:18PM +0000, Ian Jackson wrote:
> Steve Langasek writes ("Re: dpkg-shlibdeps and private libraries"):
> > On Tue, Nov 06, 2007 at 08:51:05AM +0100, Andreas Tille wrote:
> > FWIW, I don't agree that this is a fix. In one sense it makes /usr/lib
> > "cleaner" by moving private libs into a private directory; however:
> There is at least one significant difference between libraries in
> /usr/lib and ones in a private application directory: LD_PRELOAD
> cannot be used to force the loading of the latter by set-id programs.
> For example, authbind contains /usr/lib/authbind/libauthbind.so.1
> which is there for that reason. If I make a symlink into /usr/lib I
> get this behaviour:
If it's intended to only be used for LD_PRELOAD, why give it an soname at
all (i.e., why regard it as a "library")?
> -anarres:~> ll -uL --full-time /usr/lib/libauthbind.so.1
> -rw-r--r-- 1 root root 5944 2007-11-17 16:18:32.000000000 +0000 /usr/lib/libauthbind.so.1
> -anarres:~> date
> Sat Nov 17 16:19:06 GMT 2007
> -anarres:~> LD_PRELOAD=/usr/lib/libauthbind.so.1 really id
> uid=0(root) gid=100(ian) groups=0(root),4(adm),6(disk),7(lp),8(mail),9(news),24(cdrom),25(floppy),26(tape),29(audio),33(www-data),35(dos),37(operator),40(src),42(shadow),50(staff),60(games),100(ian),200(ian-p),300(exim),500(house),1143(mirror),5063(anarubun)
> -anarres:~> ll -uL --full-time /usr/lib/libauthbind.so.1
> -rw-r--r-- 1 root root 5944 2007-11-17 16:19:10.000000000 +0000 /usr/lib/libauthbind.so.1
> -anarres:~> id
> uid=100(ian) gid=100(ian) groups=0(root),4(adm),6(disk),7(lp),8(mail),9(news),24(cdrom),25(floppy),26(tape),29(audio),33(www-data),35(dos),37(operator),40(src),42(shadow),50(staff),60(games),100(ian),200(ian-p),300(exim),500(house),1143(mirror),5063(anarubun)
> -anarres:~>
> This is not desirable.
Er, no, it's not. That looks fairly special, I wasn't aware that ld.so
would happily permit LD_PRELOAD values pointing to /usr/lib when running
setuid apps.
> There are other reasons or kinds of library for which /usr/lib is not
> appropriate, for example application plugins. For example, Tcl
> extensions are moving into a separate directory.
An application plugin isn't a library, it's an application plugin.
> > - By moving the libs out of the default search path, you introduce the
> > possibility that an unrelated library will have the same name in /usr/lib;
> > this is a potential source of user confusion, as well as
> > difficult-to-diagnose corner-case bugs
> Obviously one still needs to avoid name clashes.
Which we have no mechanism for ensuring if the libraries are scattered among
multiple directories. File conflict detection is the one means we have of
finding out about name clashes.
> > So I think it's better to leave these libraries in /usr/lib instead of using
> > rpath.
> My arguments and examples above don't apply to libraries that ought to
> _only_ be autoloaded via rpath. But not all uses of rpath are wrong.
> For example the Tcl extension modules in chiark-tcl will be moving out
> of /usr/lib and because they have interdependencies, rpath will be
> needed to find them. This can't feasibly be done `by hand' in the
> Tcl-called initialisation function but there is no application which
> needs to load the top of the library stack other than Tcl.
Tcl seems to be a special case in this regard. All other languages I know
of that support loadable modules have defined search paths that are used for
this sort of thing, as well as policies governing packages' use of the
paths.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
Reply to: