[Proposal] binaries must not have rpath outside /usr/lib/<dir>/

[Bill Allombert]

Hello Debian-policy,

I would propose to forbid improper rpath in binaries.

Looking here I see 3 cases:

<http://lintian.debian.org/reports/Tbinary-or-shlib-defines-rpath.html>

1) rpath to /usr/lib/<dir>/: this is probably OK at least if the
libraries in  /usr/lib/<dir>/ are shipped in the same package
(10.2. par 6-7).

2) rpath to /usr/lib and to /usr/X11R6/lib: this is useless and can
cause problem we move /usr/X11R6/lib to /usr/lib or /usr/lib to /lib
(hurd). This has been deprecated since the libc6 transition.

3) rpath to the build environment: this can be a security hole on
a system where per chance the path lead to a user writable directory.

So I would propose for policy explicitly forbid 2) and 3).

Opinions ?

Cheers,
--
Bill. <ballombe@...>

Imagine a large red swirl here.


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

[Marco d'Itri]

On Nov 28, Bill Allombert <allomber@...> wrote:

> Opinions ?
Looks good.

--
ciao,
Marco

[Henrique de Moraes Holschuh]

On Mon, 28 Nov 2005, Bill Allombert wrote:
> So I would propose for policy explicitly forbid 2) and 3).

Agreed. In particular, 3) is a MUST NOT if I ever seen one.

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

[Ian Jackson]

Bill Allombert writes ("[Proposal] binaries must not have rpath outside /usr/lib/<dir>/"):
> 3) rpath to the build environment: this can be a security hole on
> a system where per chance the path lead to a user writable directory.

Any package like that is of course definitely wrong, and we don't need
to read the policy manual to know this.  I think this is one of those
rare cases where it's worth specifically mentioning a kind of bug that
often occurs, to help people avoid it.

I'm pointing this out because there seems to be some opposition to
putting things in the policy manual that are just obvious bugs.

> 2) rpath to /usr/lib and to /usr/X11R6/lib: this is useless and can
> cause problem we move /usr/X11R6/lib to /usr/lib or /usr/lib to /lib
> (hurd). This has been deprecated since the libc6 transition.

These are wrong too.  They are just specific examples of the problem
`rpath mentions a directory which is, or should be, in ld.so.conf'.

On the other hand, your subject says
 Subject: Re: [Proposal] binaries must not have rpath outside /usr/lib/<dir>/
which I'm not wholly convinced by.

Just as one example, a program might reasonably have an rpath in
/usr/local/lib/<package>/.  And there might be other reasons why
unusual rpaths would be right.

Ian.


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

[Bill Allombert]

On Wed, Nov 30, 2005 at 01:04:45PM +0000, Ian Jackson wrote:

> Bill Allombert writes ("[Proposal] binaries must not have rpath outside /usr/lib/<dir>/"):
> > 3) rpath to the build environment: this can be a security hole on
> > a system where per chance the path lead to a user writable directory.
>
> Any package like that is of course definitely wrong, and we don't need
> to read the policy manual to know this.  I think this is one of those
> rare cases where it's worth specifically mentioning a kind of bug that
> often occurs, to help people avoid it.
>
> I'm pointing this out because there seems to be some opposition to
> putting things in the policy manual that are just obvious bugs.

I agree, but if we are going to mention 2) we can as well mention 3)
which is actually more frequent.

> On the other hand, your subject says
>  Subject: Re: [Proposal] binaries must not have rpath outside /usr/lib/<dir>/
> which I'm not wholly convinced by.
>
> Just as one example, a program might reasonably have an rpath in
> /usr/local/lib/<package>/.  And there might be other reasons why
> unusual rpaths would be right.

My first subject (not text) was "[Proposal] binaries must not have
rpath" but I thought someone would complain so I changed it. I don't
think the subject line can ever do justice to the text. If you have a
better subject (and/or wording), be my guest!

Cheers,
--
Bill. <ballombe@...>

Imagine a large red swirl here.


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

[Henrique de Moraes Holschuh]

On Wed, 30 Nov 2005, Ian Jackson wrote:
> Just as one example, a program might reasonably have an rpath in
> /usr/local/lib/<package>/.  And there might be other reasons why

Not in Debian, it doesn't.  Since policy is about Debian *packages*, and
Debian cannot ship much more than empty dirs under /usr/local, any rpath
inside a Debian package pointing to /usr/local is a major error.

Indeed, rpath is only acceptable for:
  1. dynamically loaded modules/plugins
  2. libraries that must live outside of ld.so directories

and IMHO any case of (2) probably needs some debian-devel discursion first.

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

[Ian Jackson]

Henrique de Moraes Holschuh writes ("Re: [Proposal] binaries must not have rpath outside /usr/lib/<dir>/"):

> On Wed, 30 Nov 2005, Ian Jackson wrote:
> > Just as one example, a program might reasonably have an rpath in
> > /usr/local/lib/<package>/.  [...]
>
> Not in Debian, it doesn't.  Since policy is about Debian *packages*, and
> Debian cannot ship much more than empty dirs under /usr/local, any rpath
> inside a Debian package pointing to /usr/local is a major error.
>
> Indeed, rpath is only acceptable for:
>   1. dynamically loaded modules/plugins
>   2. libraries that must live outside of ld.so directories

And these things might reasonably be searched for in
/usr/local/lib/foo as well as /usr/lib/foo.

That way the system administrator's locally installed plugins will
be found correctly.

Ian.


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

[Henrique de Moraes Holschuh]

On Fri, 02 Dec 2005, Ian Jackson wrote:
> > Indeed, rpath is only acceptable for:
> >   1. dynamically loaded modules/plugins
> >   2. libraries that must live outside of ld.so directories
>
> And these things might reasonably be searched for in
> /usr/local/lib/foo as well as /usr/lib/foo.

rpath is for the canon location of a library.  If someone wants something
searched, he puts it (in fact, I guess we already do for him) in ld.so.conf.

There is no legal, acceptable or even remotely sane reason for a rpath
pointing to /usr/local/* *IN SOMETHING PACKAGED BY DEBIAN*.

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

[Ian Jackson]

Henrique de Moraes Holschuh writes ("Re: [Proposal] binaries must not have rpath outside /usr/lib/<dir>/"):

> On Fri, 02 Dec 2005, Ian Jackson wrote:
> > > Indeed, rpath is only acceptable for:
> > >   1. dynamically loaded modules/plugins
> > >   2. libraries that must live outside of ld.so directories
> >
> > And these things might reasonably be searched for in
> > /usr/local/lib/foo as well as /usr/lib/foo.
>
> rpath is for the canon location of a library.  If someone wants something
> searched, he puts it (in fact, I guess we already do for him) in ld.so.conf.

Let us suppose there is a program frobnicate which can load plugin
modules, with a stable and published ABI.

Now the Debian frobnicate package will come with a pile of modules in
/usr/lib/frobnicate, named /usr/lib/frobnicate/modules/frictive.so,
/usr/lib/frobnicate/modules/smooth.so, and so on.  Typically these
might be loaded because /etc/frobnicate/frobnicate.conf says `module
frictive' or some such.

A sensible way to arrange for this to work might be for
/usr/bin/frobnicate's rpath to specify /usr/lib/frobnicate/modules.
That way frobnicate can load `frictive' without having to specify the
path.

If it's done like this then /usr/local/lib/frobnicate/modules should
also be in the rpath (and it should be ahead of /usr/lib/frobnicate),
so that the sysadmin's /usr/local/lib/frobnicate/lumpy.so gets loaded
with `module lumpy' without frobnicate-loadmodule.c having to
implement a path-searching function (since the dynamic linker will do
that for us).

> There is no legal, acceptable or even remotely sane reason for a rpath
> pointing to /usr/local/* *IN SOMETHING PACKAGED BY DEBIAN*.

Please don't shout.  I heard you the first time.

Ian.


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

[Henrique de Moraes Holschuh]

On Fri, 02 Dec 2005, Ian Jackson wrote:
> A sensible way to arrange for this to work might be for
> /usr/bin/frobnicate's rpath to specify /usr/lib/frobnicate/modules.
> That way frobnicate can load `frictive' without having to specify the
> path.

Hmm... (reads ELF 1.2). Oh drat, DT_RPATH is a collon-delimited lists of
search path*s*.   Yeah, in that case it certainly makes sense to allow
/usr/local in there.

I apologise. I had forgotten you can have something like
/usr/lib/foo/bar:/usr/local/lib/foo/bar in DT_RPATH.

> Please don't shout.  I heard you the first time.

Yeah, my bad. Sorry about that.

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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