On Jun 21, 2007, at 6:20 PM, William A. Rowe, Jr. wrote:
Joe Orton wrote:
On Thu, Jun 21, 2007 at 06:18:59PM +0100, Colm MacCarthaigh wrote:
On Thu, Jun 21, 2007 at 05:51:34PM +0100, Joe Orton wrote:
On Sat, Jun 16, 2007 at 09:29:25PM -0000, Jim Jagielski wrote:
Secondly: I think this approach is unnecessarily complex. I
think it's
sufficient to simply check whether the target process is in the
right
process group before sending a signal, i.e. getpgid(pid) ==
getpgrp().
This ensures that the parent will only kill things it created.
I actually thought avoiding this was a design goal, to prevent
someone
from killing piped loggers and cgi processes ?
What's the security threat there? Given that the attacker can
arrange
for arbitrary execution of code in any unprivileged child, preventing
logging or CGI script execution is possible anyway.
Two different cases. It will be trivial to kill the CGI scripts
launched
from the process (not from cgid) for other children in, say, a worker
config. The cgid and logging processes spawned by the parents aren't
vulnerable as such (and the logging processes are spawned with the
httpd's
launching uid anyways, not nobody, IIRC.)
We only care about constraining the fallout of a malicious in process
script to that specific process, and the loggers, if we go beyond
testing
the pid group, won't have that issue from the child process.
So I agree with testing the pid groups, I also believe it is
worthwhile
to sanity test any critical data from the shared-scoreboard against
the
parent processes' private reference table.
So what's the word... should we back out all the pid table stuff
(from both 1.3 and 2.x) and wait for Joe to provide his
pgrp changes (including any required configure magic to detect
function existance) or what?
It's kind of embarrassing that this is taking so long :)
