linux-kernel - Re: [PATCH] Only send pdeath_signal when getppid changes.

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 10 Apr 2007 23:17:11 -0400
From:	"Albert Cahalan" <acahalan@...il.com>
To:	"Roland McGrath" <roland@...hat.com>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"Oleg Nesterov" <oleg@...sign.ru>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Ingo Molnar" <mingo@...e.hu>, "Robin Holt" <holt@....com>,
	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	"Chris Snook" <csnook@...hat.com>, linux-kernel@...r.kernel.org,
	"Jack Steiner" <steiner@...ricas.sgi.com>
Subject: Re: [PATCH] Only send pdeath_signal when getppid changes.

On 4/10/07, Roland McGrath <roland@...hat.com> wrote:
> > Does a parent death signal make most sense between separately written programs?
>
> I don't think it does.  It has always seemed an utterly cockamamy feature
> to me, and I've never understood what actually motivated it.

It's useful, but the other case is more important.

> > Does a parent death signal make most sense between processes that are part of
> > a larger program.
>
> That is the only way I can really see it being used.  The only actual
> example of use I know is what Albert Cahalan reported.  To my mind, the
> only semantics that matter for pdeath_signal are what previous uses
> expected in the past and still need for compatibility.  If we started with
> a fresh rationale from the ground up on what the feature is good for, I am
> rather skeptical it would pass muster to be added today.

Until inotify and dnotify work on /proc/12345/task, there really isn't
an alternative for some of us. Polling is unusable.

Ideally one could pick any container, session, process group,
mm, task group, or task for notification of state change.
State change means various things like destruction, addition
of something new, exec, etc. (stuff one can see in /proc)
With appropriate privs, having the debug-related stuff would be
good as well.
-
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/