linux-kernel - Re: Inconsistency between PTY read() return values

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, 8 Apr 2009 17:47:16 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Ed Schouten <ed@...eBSD.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Inconsistency between PTY read() return values

> 	-1
> 	read: Input/output error
> 
> I looked through the standards and it seems the POSIX onlinepubs don't
> mention the behaviour of pseudo-terminal master file descriptors at all.
> This means it would even be valid of we return 0x1337 or something.
> 
> But still, I think it's a little inconsistent. Most programmers would
> expect pseudo-terminal master file descriptors to behave somewhat
> similar to TTYs, even though they don't need to be. When you try to

I would argue that TTYs do behave this way. We treat the disconnect as a
hang up event. BSD sees it as EOF, Linux as hangup.

> perform a read() on the TTY after the master file descriptor gets
> closed, you get an end-of-file. You only get an EIO when trying to write
> to this descriptor.
> 
> Would it be hard to change the Linux TTY code to behave the same?

Probably not vastly so, but given it has been this way for over ten years
and causes no problems I don't think it makes sense to do so.

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