lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ