| 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
| ||
|
Message-ID: <DAF636D3923A51488784A1F985996EE804207065@exil1.paradigmgeo.net> Date: Thu, 4 Nov 2010 16:20:37 +0000 From: Gregory Giguashvili <Gregory.Giguashvili@...M.com> To: Alan Cox <alan@...rguk.ukuu.org.uk> CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: RE: Change signal mask after vfork/clone system call > And is there a reason you can't mask the signals, vfork and unmask them > again after the parent continues? The signals are already masked in all threads and there's a dedicated thread, catching signals with sigwait. The problem is that vfork inherits signal mask to a child process and 3rd party executables are not processing any signals because they're not using sigwait technique. Now, I could unmask signals for the thread calling vfork, but it seems not a signal-safe solution to me because signals may arrive to this thread until I reestablish the mask. pthread_atfork call comes to rescue to address such issues for fork, but there seems to be nothing for vfork call. Giga --------------------------------------------------------------------------------------------------------------- This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message. -- 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