Re: [Proposal] binaries must not have rpath outside /usr/lib/<dir>/
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.
Reply to: