linux-kernel - Re: regression, bisected: openpty fails from 3.7 onwards without devpts

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:	Thu, 10 Jan 2013 22:45:54 +0000
From:	Alan Cox <alan@...ux.intel.com>
To:	Jiri Slaby <jslaby@...e.cz>
Cc:	Florian Westphal <fw@...len.de>, linux-kernel@...r.kernel.org,
	gaowanlong@...fujitsu.com, gregkh@...uxfoundation.org,
	frank@...htenheld.de
Subject: Re: regression, bisected: openpty fails from 3.7 onwards without
 devpts

> getptsname expects EINVAL on failure to fall back to /dev/ttyp*... The
> same as unlockpt. We should definitely revert now and can teach glibc
> to accept also ENOTTY. After some years, we can try again :).

Strongly disagree for two reasons

1. We don't want to leave the other ioctls broken and non-compliant if
we can avoid it.

2. The userspace code here has quite reasonable expectations which are
that TIOCGPTN is not an unknown ioctl but is invalid to use in this
situation.

So we should just fix TIOCGPTN on a pty with no suitable name answer to
return -EINVAL (even though it would be fun to break userspace and make
Linus teach more rude words to non English speakers).

In this case I think the userspace expectations are actually perfectly
fair anyway even without considering the rather important criterion
of 'it worked last week')

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/