linux-kernel - Re: [PATCH] emit logging when a process receives a fatal signal

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:	Sun, 19 Nov 2006 00:24:14 +0100 (MET)
From:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
To:	Oleg Verych <olecom@...wer.upol.cz>
cc:	Folkert van Heusden <folkert@...heusden.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] emit logging when a process receives a fatal signal


On Nov 18 2006 21:51, Oleg Verych wrote:
>On Sat, Nov 18, 2006 at 08:30:02PM +0100, Jan Engelhardt wrote:
>> >Then, who you think prints that "Killed" or "Segmentation fault"
>> >messages in *stderr*?
>> >[Hint: libc's default signal handler (man 2 signal).]
>> 
>> Please enlighten us on how you plan to catch the uncatchable SIGKILL.
>
>Here's question of getting information. Collecting information is
>possible by `waitpid()' from parent process as Miquel noted.

Yes, that is true. However that would involve adding support for This 
Situation to the parent process. Which is where it becomes tricky. Patch 
/sbin/init, in case the daemon runs like everything else. Or patch 
xinetd, in case it is run from within that. Or, ...
  The 'problem' with the waitpid solution is that you would need to 
patch every possible parent that may become the owner of The Sigkilled 
Target.

>That man above, gave me impression, that SIG_DFL can not be changed in
>case of KILL and STOP signals, what yields to "The signals SIGKILL and
>SIGSTOP cannot be caught or ignored." Implementation of such no-action
>can be different. In case if kernel just stops processing of task with
>STOP, breaks with KILL, without giving a chance to flush any pending data
>OK, if this is an assembler prorgam with just data segment and no
>infrastructure at all. But i think (didn't read anything), it is bad, if
>there's libc with standard stream I/O buffers and no callback is possible.

	-`J'
-- 
-
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/