Re: glibc and Unix98 PTY's

["H. Peter Anvin" <hpa@transmeta.com>]

>    Date: 	8 Aug 1998 23:20:27 GMT
> 
>    I just realized that glibc uses the TIOCGPTN ioctl() to determine the
>    name of a PTY opened using /dev/ptmx.  Currently, this returns the
>    minor number which isn't quite right for 2.1.115 and above which has
>    pty's on multiple majors.  I would like to suggest the following
>    change in semantics for TIOCGPTN, please holler if you object:
> 
>    TIOCGPTN will be undefined (returning -1 errno=ENOIOCTLCMD) on BSD
>    ptys (BSD ptys can no longer be opened using /dev/ptmx due to a
>    security hole that opens); TIOCGPTN will return the PTY number (which
>    may be different from the minor number) for Unix98 PTYs,
>    i.e. /dev/pts/316 (137,60) would return 316.
> 
>    I suspect this will make glibc do the right thing in all cases, but I
>    wanted to double-check here first.  Please let me know yea/nay as soon
>    as possible.
> 
> Yea, this sounds to me as the way it should have been implemented
> right from the start.  A clear distinction between BSD-style and
> SYSV-style pty's.  Some small changes in the glibc code will be
> necessary but they will be simplifications rather than complications.

Good.  I have send the patch to do this to Linus; hopefully it should
be included in 2.1.116.

> This raises the following question.  Should the orthogonality between
> BSD-style and SYSV-style pty's be reflected in the function glibc
> defines?  Thus
> 
>  * openpty()/forkpty() - operate on BSD-style pty's only.
> 
>  * getpt(), granpt(), unlockpt(), ptsname() - operate on SYSV-style
>    pty's only.
> 
> For openpty and forkpty, I think this is a good idea since there may
> be programs out there that assume that when they use openpty() they
> get a pair named `/dev/pty??', `/dev/tty??' (or what is more
> important, that the terminal is a file in the directory `/dev' and not
> in a subdirectory.  Especially programs that do utmp accounting would
> be unpleasently surprised.

This does look quite reaonable to me.

> For the other functions it is not really necessary.  If they can do
> their job, let them do it.
> 
> What do we do with 2.1.7x < kernel < 2.1.115, where TIOCGPTN has the
> old semantics?  I'd say that we do not support them, since we're
> talking about development versions of both the kernel and glibc.  But
> it might cause some inconveniences..

Well, 2.1.7x < kernel < 2.1.115 didn't have the BSD/Unix98 PTY
distinction at all, instead alias the two of them, so I would say
"ignore them and if they're lucky they might actually work."  They are
fundamentally insecure anyway, so I don't think it matters.  As you
point out, they are development versions and will probably quickly
fade into obscurity.

2.1.115 itself is the main problem, but I think we can just classify
that one as a temporary bug.

> PS I'm not sure what the linux-gcc list is for anymore, but the glibc
> hackers can be reached at libc-hacker@cygnus.com.

Cool, thanks.

	-hpa