linux-kernel - Re: [PATCH 7/7][v7] proc: Show SIG_DFL signals to init as "ignored" signals

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:	Tue, 20 Jan 2009 08:33:05 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>
Cc:	ebiederm@...ssion.com, roland@...hat.com, bastian@...di.eu.org,
	daniel@...ac.com, xemul@...nvz.org, containers@...ts.osdl.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 7/7][v7] proc: Show SIG_DFL signals to init as
	"ignored" signals

On 01/19, Sukadev Bhattiprolu wrote:
>
> Oleg Nesterov [oleg@...hat.com] wrote:
> | On 01/17, Sukadev Bhattiprolu wrote:
> | >
> | > Init processes ignore SIG_DFL signals unless they are from an ancestor
> | > namespace.  Ensure /proc/pid/status correcly reports these signals.
> |
> | This is the user-visible change, and I don't really understand why do we
> | need it.
>
> This discussion came up earlier, with Bastian and Roland and my understanding
> was that we should fix the SigIgn line in /proc/pid/status - so I had added
> a TODO for this patchset.

Hmm. I must admit I don't understand what this patch buys us. Admin should
know that init is special and can't be killed by the SIG_DFL signal.

Now we change the contents if pid/status, and every user-visible change
should have a good reason, imho.

> | Imho, this patch can confuse the user-space. Why should we report that,
> | say, SIGCONT is ignored by the global init?
>
> But it is ignored right ?

Following this logic, we can report that, say, SIG_DFL'ed SIGWINCH is always
ignored by any task, not only by init?

> Also, if user space looks at the SigIgn line and assumes that SIGKILL or
> SIGUSR1 will kill init, user space can still be confused when it doesn't
> really kill - no ?

yes, but this is oddity is very old.

But, otoh, SIGCHLD. There is a huge difference between SIG_IGN and SIG_DFL
in that case, why should we hide it?

More generally, why should we hide from admin what init does with signals?

> So, should I just post separately or drop altogether ?

I guess you already see that personally I dislike this patch ;) At least
I'd ask you to not mix it with this series.

But perhaps I am wrong, I can't "prove" this change is not good, I'd be
ready to agree with majority.

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/