FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 11-17-2007, 06:28 PM
Steve Langasek
 
Default 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(s taff),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(s taff),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/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-17-2007, 06:36 PM
Steve Langasek
 
Default dpkg-shlibdeps and private libraries

On Tue, Nov 13, 2007 at 08:59:32PM +0100, Josselin Mouette wrote:

> Le mardi 13 novembre 2007 à 11:01 -0800, Steve Langasek a écrit :
> > > The current packages install the dynamic libraries simply to /usr/lib
> > > which I want to fix now. They should go to

> > > ${ARB_HOME}/lib

> > 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:

> > - Because Debian uses ldconfig, the runtime cost of having additional
> > libraries in the search path for other apps is negligible
> > - 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

> But when you keep private libraries without a stable ABI nor proper
> soname versioning, you increase the chance that other packages start
> using them without thinking.

If that's really the case here, then moving the lib out of /usr/lib is a
reasonable option. I think other reasonable options are to not ship a -dev
package for the library, or (depending on how big the library is and how
much the privately-cooperating binaries benefit from using a shared library)
only making the lib available as a static lib.

> > - When multiarch matures (or we have some other reason to move library
> > directories around...), your package will require specific handling to
> > update the library paths, rather than a simple change to libdir that will
> > be handled automatically by the ld.so search path.

> Given the number of specific binaries and libraries in this case, I hope
> we will have some generic tools to make them support multiarch.

That's not really possible when you're dealing with packages which
individually have their own way of hard-coding their private search paths.

--
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/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 01:37 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org