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
| ||
|
Date: Wed, 12 Nov 2008 11:04:21 -0800 From: Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com> To: Oleg Nesterov <oleg@...hat.com> Cc: "Eric W. Biederman" <ebiederm@...ssion.com>, Pavel Emelyanov <xemul@...nvz.org>, daniel@...ac.com, Nadia Derbey <Nadia.Derbey@...l.net>, serue@...ibm.com, clg@...ibm.com, Containers <containers@...ts.osdl.org>, sukadev@...ibm.com, linux-kernel@...r.kernel.org Subject: Re: Signals to cinit Oleg Nesterov [oleg@...hat.com] wrote: | On 11/10, sukadev@...ux.vnet.ibm.com wrote: | > | > Also, what happens if a fatal signal is first received from a descendant | > and while that is still pending, the same signal is received from ancestor | > ns ? Won't the second one be ignored by legacy_queue() for the non-rt case ? On second thoughts, cinit is a normal process in its ancestor ns so it might very well ignore the second instance of the signal (as long as it does not ignore SIGKILL/SIGSTOP) | | Please see my another email: | | We must also change sig_ignored() to drop SIGKILL/SIGSTOP early when | it comes from the same ns. Otherwise, it can mask the next SIGKILL | from the parent ns. Ok. | | But this perhaps makes sense anyway, even without containers. | Currently, when the global init has the pending SIGKILL, we can't | trust __wait_event_killable/etc, and this is actually wrong. | | We can drop other SIG_DFL signals from the same namespace early as well. I think Eric's patchset did this and iirc, we ran into the problem of blocked SIG_DFL signals ? | I seem to already did something like sig_init_ignored(), but I forgot. Yes, I think we had that in the patchset but that was not merged. | | Or, we can just ignore this (imho) minor problem. I think so too. | The ancestor ns | must know it can't reliably kill cinit with (say) SIGTERM. It can | be ignored, or it can have have a handler, and it can be lost because | SIGTERM is already pending. Only SIGKILL is special. | | Actually. I personally think that if we manage to achieve that | | - the sub-namespace can't kill its init | | - the ancestor can always kill cinit with SIGKILL Yep. | | then imho we should not worry very much about other issues ;) | | Oleg. -- 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