On 08/09/2011 08:47 AM, Steve Grubb wrote:
> My main concern is that the macro will be misapplied and overall performance
> will take a hit. I don't know how a macro can tell the intent of an
> application as it links it. There has not been a chmod so that it knows this
> is setuid and needs more protection. For example, if coreutils was built
> with this (and coreutils seems to be correct as is) because it has setuid
> programs, then would all apps get the PIE/Full RELRO treatment? If so, many
> of coreutils apps are called constantly by shell scripts. If this were used
> on tcpdump, would full relro leak to the libpcap? I suppose I could test this
> as soon as I set up a rawhide vm...but this is what concerns me about the
> approach.
I think invoking coreutils is a pretty bogus example since it's full of
relatively small binaries which don't take long to relocate. That being said,
you don't *have* to use the macro. If your package needs a more nuanced
approach to PIE and relro, and needs choices to be made on a per-binary
basis, that's fine. There are a couple of approaches you could use here,
most obviously just writing your makefile to be aware of these requirements.
You own your packages and their makefiles. Knock yourself out.
--
Peter
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
