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-next>] [day] [month] [year] [list]
Date:	Sat, 22 Sep 2007 11:22:09 -0700
From:	"John Z. Bohach" <jzb2@...orsyst.com>
To:	linux-kernel@...r.kernel.org
Subject: Should parent's WIFSIGNALED(siginfo->si_status) be true EVEN IF the SIGNAL was caught by the child?

Hello,

It is unclear from the various documentions in the kernel and glibc what 
the proper behaviour should be for the case when a child process 
catches a SIGNAL (say for instance, SIGTERM), and then calls exit() 
from within its caught SIGNAL handler.

Since the exit() will cause a SIGCHLD to the parent, and the parent 
(let's say) has a SIGCHLD sigaction (SA_SIGINFO sa_flags set), should 
the parent's WIFSIGNALED(siginfo->si_status) be true?

To recap, the WIFSIGNALED section of the waitpid() manpage says:

WIFSIGNALED(status)
    returns true if the child process was terminated by a signal.

So the dilemna:  the child caught the signal, so it wasn't terminated by 
a signal, but rather its signal handler (let's say) called exit.

Furthermore:

WTERMSIG(status)
    returns the number of the signal that caused the  child  process
    to  terminate. This macro should only be employed if WIFSIGNALED
    returned true.

Observered behaviour with 2.6.20.6 is that is WIFSIGNALED(status) 
returns true (possibly incorrect), and furthermore, WTERMSIG(status) 
returns the exit(VALUE) VALUE from the child's exit() call, and not the 
SIGNAL (let's say SIGTERM that the child caught).  This may be correct, 
since the siginfo_t * si_status member is:

int      si_status; /* Exit value or signal */

but there's no clarity on which:  exit value or signal.  Since the child 
exited, I'm likely to assume exit status, which is current observed 
behaviour, but then, WIFSIGNALED(status) should be FALSE, which its not 
(observed with 2.6.20.6).

So could someone clarify the kernel's intent?

I can provide a short C program to illustrate above behaviour, if 
needed.  It also could be that I'm just misinterpreting the intent, 
which is why I'm not calling this a bug, despite a possible 
inconsistency in behaviour.

Thanks,
John


-
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