Bug#493705: libswscale0: The library has text relocations
Russell Coker
russell at coker.com.au
Mon Aug 4 12:04:22 UTC 2008
On Monday 04 August 2008 20:59, Loïc Minier <lool at dooz.org> wrote:
> On Mon, Aug 04, 2008, Russell Coker wrote:
> > http://etbe.coker.com.au/2007/02/10/execmod/
> >
> > The above URL has background information on the execmod denial from SE
> > Linux.
>
> If you want to file bugs about binaries not using -fpic / -fPIC on
> i386, then I think you need to start a wider discussion on
> debian-devel@: this was debated and I understand there's now an
> exception for performance critical code (such as libswscale's case):
> <http://www.debian.org/doc/debian-policy/footnotes.html#f61>
The references you provide seem to indicate that the exception is for the case
where faster assembly is not available. IE you have a choice between fast
assembly and a slower compiled language. While if the difference is only 10%
(between two different versions of assembly code) then PIC is the way to go.
I expected that the probability of you including my patch to disable the
assembler was low (although a similar patch is in the Fedora tree for
libtheora), but if nothing else it clearly illustrates where the problem is
for anyone who wants to have a go at writing some assembler.
> I see two ways to go forward: implement a way to disable execution of
> such binaries when under SELINUX, or force usage of -fPIC, even in
> performance critical code.
If the performance critical code is going to be handling data from sources of
low integrity (EG playing video downloaded from youtube etc) then I think
that we want all the available security features enabled!
But having library A try and load library B at runtime and then load library C
if B fails (where B is the non-PIC version and C is the PIC version) would be
a viable option.
More information about the pkg-multimedia-maintainers
mailing list