On Wed, 2012-04-11 at 10:51 -0400, Daniel J Walsh wrote: > On 04/11/2012 10:21 AM, Matthew Garrett wrote: > > I'm in favour of keeping ptrace available for F17 - I don't think we've had > > enough opportunity to discuss the tradeoffs. > > > deny_ptrace will be DISABLED for F17. Already checked in. Thanks, and again apologies we are having this discussion so late into the release. But at least everybody should now be well aware this will come back for F18. > I think we can have levels of denial. Once we can separate out gdb foobar from > gdb -p 1234, we can have multiple booleans, to deny different accesses, and > allow the administrator to choose which level can be blocked. Do you have an overview how to handle all these layers/booleans? At times it seems this is only about gdb, but this does break a lot more stuff out of the box when enabled. Of course there is strace and ltrace. But also things that use gdb underneath like pstack, gcore, or IDEs like eclipse or nemiver. Crash interceptors, like KDE's DrKonqui, but I believe firefox and chrome also come with their own (abrt for now works around it by dumping a core file to disk and then examining that, but that seems a little wasteful IMHO). java tools like jinfo/jmap/jstack use ptrace to provide users information about system properties, memory usage, java backtraces, etc. of running java processes, wine uses ptrace for some of its inter-process communication. If you could create an overview how all these things are handled (hopefully by making them just work out of the box, and not requiring people to unbreak their box or having to use root privileges) with the feature enabled by default that would be really appreciated. Some of these programs don't provide much help or just plain crash if ptrace is globally disabled. So there should at least be an effort to clean them all up and make them aware of the different ways ptrace may fail (somewhat complicated by the fact that it seems there is just one generic EPERM error given, whether it really is not your process or something like SELinuxDenyPtrace). Thanks, Mark -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
