linux-kernel - Re: Why are not processes HUPped when they open /dev/console?

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] [day] [month] [year] [list]

Message-ID: <4F30F5C4.6030003@suse.cz>
Date:	Tue, 07 Feb 2012 10:58:28 +0100
From:	Jiri Slaby <jslaby@...e.cz>
To:	Pavel Machek <pavel@....cz>
CC:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Greg KH <greg@...ah.com>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: Why are not processes HUPped when they open /dev/console?

On 02/06/2012 08:24 PM, Pavel Machek wrote:
>> On 01/25/2012 10:45 PM, Alan Cox wrote:
>>> On Wed, 25 Jan 2012 22:38:40 +0100
>>> Jiri Slaby <jslaby@...e.cz> wrote:
>>>
>>>> Hello,
>>>>
>>>> don't you remember by a chance the reason for this test in __tty_hangup:
>>>>   if (filp->f_op->write != tty_write)
>>>>
>>>> The logic there is not to HUP processes that have this tty open via
>>>> /dev/console.
>>>
>>> Because if you hang up the console the machine crashes ?
>>>
>>> At least that's what used to happen.
>>
>> It does not crash anymore. However the system (systemd more precisely)
>> is confused a bit (well, a huge). So I suppose the test has its meaning.
>>
>> The whole exercise was about how to fix the userspace issue introduced
>> by the added infinite timeout.
> 
>> I think the proper solution here is just not to call vhangup in
>> userspace for the device which is /dev/console. It never worked anyway.
>> Because the HUP signal was never sent and it always timed out.
> 
> Perhaps the "infinite timeout" should be reverted, then? It sounds
> like a regression...

It *is* a regression in the shutdown path, yes. The point is that
previously it silently proceeded and freed the structures. This was
causing crashes. And it also misbehaved as it was supposed to wait for
all to vanish.

OTOH now it (possibly infinitely) waits for all of them. With the code
as it stands now, I cannot think of any other easy way to fix that. Do
what you have to. Revert, if you think occasional (nearly exceptional)
crashes are better than the regression...

thanks,
-- 
js
suse labs
--
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/