Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!pilchuck!pacer!davidb
From: davidb@Pacer.UUCP (David Barts)
Newsgroups: comp.unix.wizards
Subject: Re: Session management
Summary: allocating a pty
Keywords: pty login daemon session
Message-ID: <360@pacer.UUCP>
Date: 28 Aug 90 17:30:50 GMT
References: <6038@muffin.cme.nist.gov> <3954@auspex.auspex.com> <105387@convex.convex.com>
Organization: Pacer Corp., Bothell, WA
Lines: 34

In article <105387@convex.convex.com>, tchrist@convex.COM (Tom Christiansen) writes:
> :
> :
> I'd like to solve at least these problems:
> 
>     1. getting the pty name right (varies system to system)
>     2. race condition between choosing a name and trying the open
> . . .

I thought master pty's only allowed one open at a time (at least that's
what the HP-UX docs say).  So choosing a name is easy -- just read
through the /dev directory (or wherever the ptys are).  For each name
that matches the naming convention of a master pty, try to open it.  If
the open succeeds, you have your pty pair.  (You can't open a closed
master pty whose slave is still open, because that will fail also.)

The only possible problem that I see is if some other unwanted process
opens your slave pty.  But this can be solved by keeping all the ptys
owned by root and not world read- or writable (to limit use of ptys to
trusted programs that follow this opening protocol).  So I can see
where the need for suid programs and chown()ing comes in, but I can't
see the race condition, since choosing the name and trying the open are
the same step.

Am I missing something here?  (I looked in the man pages for our
Solbourne system, and couldn't find anything as detailed as the rules
laid out in the HP man pages for when a master pty will open.) Is this
behavior of master pty's unique to HP-UX?

The one time I wrote a program that used ptys, I used the above
approach and it seemed to work just fine.
-- 
David Barts			Pacer Corporation, Bothell, WA
davidb@pacer.uucp		...!uunet!pilchuck!pacer!davidb