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

Message-ID: <20090408143631.GH32098@hoeg.nl>
Date:	Wed, 8 Apr 2009 16:36:31 +0200
From:	Ed Schouten <ed@...eBSD.org>
To:	linux-kernel@...r.kernel.org
Subject: Inconsistency between PTY read() return values

Hi all,

Some time ago I noticed this small inconsistency between the return
values of read() calls on pseudo-terminal master devices while working
on the FreeBSD TTY code.

Consider the following example:

| #include <fcntl.h>
| #include <stdio.h>
| #include <stdlib.h>
| #include <unistd.h>
| 
| int
| main(int argc, char *argv[])
| {
| 	int f1, f2;
| 	char buf[20];
| 	ssize_t r;
| 
| 	f1 = posix_openpt(O_RDWR|O_NOCTTY);
| 	grantpt(f1);
| 	unlockpt(f1);
| 
| 	f2 = open(ptsname(f1), O_RDWR);
| 	close(f2);
| 
| 	r = read(f1, buf, sizeof buf);
| 	printf("%zd\n", r);
| 	if (r == -1)
| 		perror("read");
| 
| 	return (0);
| }

The code is very simple. It acquires a pseudo-terminal, opens the slave
device and closes it. After that it tries to perform a read() on the
pseudo-terminal master device. On at least Solaris 7 to 10, Mac OS X
10.5 and FreeBSD 6 to HEAD, this code just prints 0. On Linux
(at least 2.6.22-2.6.28) I see the following:

	-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
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?

-- 
 Ed Schouten <ed@...eBSD.org>

Content of type "application/pgp-signature" skipped