[1907] in Kerberos-V5-bugs
pty_getpty() assumes small numbers of ptys on some OSes
daemon@ATHENA.MIT.EDU (John Hawkinson)
Thu May 2 18:46:37 1996
Date: Thu, 2 May 1996 18:46:26 -0400 (EDT)
To: krb5-bugs@MIT.EDU
Cc: shostack@bbnplanet.com
From: John Hawkinson <jhawk@bbnplanet.com>
We recently (like half an hour ago) finished kludging together support
for more than 256 ptys under SunOS. This involved cloning the pty
devices driver and a two new major device numbers and assorted
nasty hackery -- send me mail if you want details.
Anyhow, we observed that SunOS rlogind/telnetd seem to allocate
ptys based on the assumption that there would be only 256
of them (/dev/ttyp[p-zP-T][a-f]), and so contains:
[all-purpose-gunk!jhawk] ~> strings -o /usr/etc/in.telnetd | grep PQR
17389 pqrstuvwxyzPQRST
Presumably a for loop iterates through this, like in telnet.95.10.23:
for (cp = "pqrstuvwxyzPQRST"; *cp; cp++) {
struct stat stb;
[...]
The util/pty/getpty.c code currently in the k5 sandbox (it'd be
convenient if symlinks existed there...) ultimately falls back to:
for (c = 'p'; c <= 's'; c++) {
which is the same thing that was in the 4.3bsdnetwork2 telnetd. In
the interest of expediency, we'll probably change our pty-openning
clients to use something like:
for (cp = "pqrstuvwxyzPQRSTUVWXYZ0123456789"; *cp; cp++) {
but k5 and dab should implement something better, but I'm not sure
what that is. Anyone have an suggestions? It's not immediately
apparent what naming scheme to use for the >256th ptys. Certainly
using U-Z seems clear, but then going up to 0-9 is not necessarily the
same thing other people might do, so I'm not sure that's the right
implementation.
Any suggestions? (Sam? :-)) If no one has any, the k5 code should at
least be fixed to use t-zP-T (sunOS compatibility), and maybe U-Z if
you're feeling nice.
I decided against cc-ing dab and/or telnet-ietf, but I suppose
if no one has any good theories, that's a place to start.
--jhawk
