On Nov 11, 10:07am, jonathan@dsg.stanford.edu (Jonathan Stone) wrote:
-- Subject: Re: ptyfs fully working now...

| In message <I70p2q.JKw@tac.nyc.ny.us>,Christos Zoulas writes:
| >In article <20041111111145.44355b01.rpaulo@netbsd-pt.org>,
| >Rui Paulo <rpaulo@netbsd-pt.org> wrote:
| 
| >I don't understand the question. I just removed all the pty's and rebooted
| >with ptyfs mounted. I don't think that you can disable one specifically.
| 
| Hi Christos, 
| 
| A question: consider the security-paraonid (or change-resistant
| troglodytes, if you prefer) amongst us who would rather "Just Say No"
| to anything that smacks of devfs, and would rather statically
| preconfigure everything, existing pty warts and all.
| 
| Where does your ptyfs leave us^H^H, er, them?

I think that it will end up being safer than the old ptys when the bugs
have been ironed out because:

1. You cannot have access to the pty master node through the filesystem.
   I.e. there is no /dev/ptyXX; you get a reference to a file descriptor
   from /dev/ptm or /dev/ptmx, but there is no physical device node.
2. The slave node again gets created only through the multiplexor, and
   the psysical node directly appears owned either by root, or by the
   user (*).

(*) There is some compatibility code there that needs to go away, but
eventually that will be true.

So there is no "I forgot to revoke" problem of lingering processes holding
file descriptors to ptys. With non-multiplexed pty's you can have the
old problem where programs forget to revoke ptys before allocating them.

By removing /dev/ptyXX and /dev/ttyXX you force old code to break, and
you find all the programs that scan through /dev to find ptys, instead
of using openpty(3) and or posix_openpt(3). The only one I found so far
was xconsole, and I fixed it already. Guess what? xconsole was not calling
revoke(2) on the pty it allocated...

christos