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:	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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ