jk> Yes, but /if/ KTRACE is present, today's code allows you to bypass jk>the lack of read permissions on an executable. That shouldn't be jk>allowed. The current behaviour could be regarded as a security jk>hole actually :). sef> No more so than core dumps do. Yes, but an application can protect itself from an inadvertent core dump. It can't (today) against being ktrace'd. sef> I vote strongly against this change. Noted, thanks. I will summarize the result of the discussion in a followup to kern/3546. Regards, Koshy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
- deny ktrace without read permissions? jkoshy
- Re: deny ktrace without read permissions? Greg Lehey
- Re: deny ktrace without read permissions? Nate Williams
- Re: deny ktrace without read permissions? jkoshy
- Re: deny ktrace without read permissions? Sheldon Hearn
- Re: deny ktrace without read permissions... Warner Losh
- Re: deny ktrace without read permissions? Nate Williams
- Re: deny ktrace without read permissions? Nate Williams
- Re: deny ktrace without read permissions? Sean Eric Fagan
- Re: deny ktrace without read permissions? jkoshy
- Re: deny ktrace without read permissions... Sean Eric Fagan
- Re: deny ktrace without read permis... Warner Losh
- yet more ways to attack executing binari... Robert Watson
- Re: yet more ways to attack executi... Chris Costello
- Re: yet more ways to attack exe... jkoshy
- Re: yet more ways to attack... Dominic Mitchell
- Re: yet more ways to attack... Nate Williams
- Re: yet more ways to attack... Chris Costello
- Re: yet more ways to attack... Nate Williams
- Re: yet more ways to attack... Matthew Dillon

