[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080325220042.87CFD26FA0A@magilla.localdomain>
Date: Tue, 25 Mar 2008 15:00:42 -0700 (PDT)
From: Roland McGrath <roland@...hat.com>
To: Andi Kleen <andi@...stfloor.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Oleg Nesterov <oleg@...sign.ru>, ebiederm@...ssion.com,
xemul@...nvz.org, pavel@....cz, sds@...ho.nsa.gov,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ptrace: it is fun to strace /sbin/init
> It would be fine to allow this unconditionally if there was some mechanism
> to make sure someone else takes over reaping childs while init is ptraced.
I don't see why this particular issue is any special case. The zombie leak
is just one of many ways that the system might become unusable if root does
the wrong thing to an essential system daemon. Caveat superusor. Diddling
with init on a system you expect ever to do anything again is dangerous and
requires great care. The question of allowing an administrator to engage
in dangerous activities is orthogonal to the details of a particular danger.
With today's kernel, init can avoid any reparented zombies collecting if it
doesn't care about its own children either. That is, it can ignore SIGCHLD
or set SA_NOCLDWAIT to make all its children clean themselves up. That
doesn't help for a normal init, which does care (for respawn and logging).
(Also it's never been tried, and I'm almost sure it has a bug. But that's
supposed to be the semantics.)
That said, the orthogonal question of orphan zombies may well be worth
addressing too. Just let's not conflate it with the ptrace question.
(AFAIK there is no good reason not to make orphans just self-reap, it's
just hysterical raisins inherited from the dawn of Unix. I'm sure that
Oleg and I can work out the cleanups, but in a separate thread please.)
Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists