linux-kernel - Re: n_tty: Check the other end of pty pair before returning EAGAIN on a read()

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: <alpine.WNT.2.00.1601141448530.844@CLUIJ>
Date:	Thu, 14 Jan 2016 14:50:09 -0700 (Mountain Standard Time)
From:	Marc Aurele La France <tsi@...oix.net>
To:	Peter Hurley <peter@...leysoftware.com>
cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jiri Slaby <jslaby@...e.com>, linux-kernel@...r.kernel.org,
	Volth <openssh@...th.com>, Damien Miller <djm@...drot.org>
Subject: Re: n_tty: Check the other end of pty pair before returning EAGAIN
 on a read()

On Fri, 18 Dec 2015, Marc Aurele La France wrote:
> On Fri, 18 Dec 2015, Peter Hurley wrote:
>> On 12/18/2015 06:26 AM, Marc Aurele La France wrote:
>>> On Fri, 11 Dec 2015, Peter Hurley wrote:
>>>> On 12/11/2015 05:37 AM, Marc Aurele La France wrote:

>>>>> I am not asking to read data before it has been produced.  I am puzzled
>>>>> that despite knowing that the data exists, I can now be lied to when I
>>>>> try to retrieve it, when I wasn't before.  We are talking about what is
>>>>> essentially a two-way pipe, not some network or serial connection with
>>>>> transmission delays userland has long experience in dealing with.

>>>>> These previously internal additional delays, that are now exposed to
>>>>> userland, are simply an implementation detail that userland did not,
>>>>> and should not, need to worry about.

>>>> Your mental model is that pseudo-terminals are a synchronous pipe, which
>>>> is not true.

>>>> But this argument is pointless because the regression needs to be fixed
>>>> regardless of the merits.

>>> Fair enough.

>>> Anything new on this?

>> It's on my todo list.

>> While considering this issue further, I was curious what ssh does
>> regarding the entire foreground process group and its output?

>> If ssh only knows that the child has terminated, how does it wait
>> for the rest of the foreground process group's output since those
>> processes may not yet have received their SIGHUP/SIGCONT signals
>> yet?

> sshd cannot know about the termination of any process other than the
> session leader because any of the session leader's children are
> re-parented to init.  The idea is to, at minimum, collect any output the
> session leader might have left behind.  Yes, this could entail also
> collecting output from its children that might have squeaked in, but
> that's gravy that can't be avoided.

> This situation is much simpler on the *BSDs.  There, both ends of the
> pty pair are, in effect, completely closed after disassociation of either
> end, preventing (with EIO) any further output (but still allowing data
> already collected to be read, after which an EIO occurs).  It's
> unfortunate System V variants don't do this, but that's crying over spilt
> milk.

Anything more on this?

Thanks.

Marc.