Re: PTY feature? or bug?

really kuznet@ms2.inr.ac.ru (inr-linux-kernel@ms2.inr.ac.ru)
26 Apr 1996 18:33:29 +0400


Robert de Bath (robert@mayday.COMpulink.co.UK) wrote:

: On 24 Apr 1996 inr-linux-kernel@ms2.inr.ac.ru wrote:

: > I'd like to repeat my question.
: > Are you sure, that it should wait for master open?

: > I'd propose return EIO (EAGAIN,....) on the attempt to
: > open orphaned pty slave. If BSD does not make it, it is
: > BSD's bug, I believe.
: BAD idea, it's occasionally useful to have init put a getty on the slave
: side of one of the higher pty numbers, some other non-aware program can
: then be told to open the master side. An example is to provide DOSEMU
: with a simulated serial line to the linux machine.

This idea looks nice. But...
Please read my previous message.

SYSV developers choosed the different scheme.
(but SYSV has more versatile STREAMS interface, it is possible
that your trick is possible on SYSV too)

1. If master is not opened, slaves generate EPERM
2. When master is opened, slave side generates EPERM too.
3. Master changes ownership/permissions of slave with the help of pt_chmod
4. Master unlocks slave. Only now anyone is allowed to open pty.

(Note, that Solaris has emulated BSD style ptys, which
block in open call, as you wanted.)

BSD has much more poor interface, that FORCES you to call vhangup
after any master open. If you'd like use your trick you must
find a method to reset permissions/ownership of slaves to 600/root
after finishing any pty session.
(yes, emacs shell will stop to work)

Unfortunately, Linux kernel has unresolved race condition,
described in my message of yesterday, that makes impossible
secure handling of ptys.

Maybe, Ted will find a workaround, but for now
I do not see no solution besides making slave open ATOMIC
and, hence, disabling blocked slave open.

Alexey Kuznetsov.