linux-kernel - Re: Signals to cinit

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]

Message-ID: <20081112150555.GB13269@redhat.com>
Date:	Wed, 12 Nov 2008 16:05:55 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	sukadev@...ux.vnet.ibm.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

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 ?

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.

	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 seem to already did something like sig_init_ignored(), but I forgot.

Or, we can just ignore this (imho) minor problem. 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

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/