Re: Attention 7.x and 8.x ptmx/pts users (read if you set kern.pts.enable=1)

* Robert Watson <rwatson_at_FreeBSD.org> wrote:
> Unfortunately, the current implementation is subject to a potential 
> resource leak: the pty is created when the lookup occurs, but if the open 
> never takes place, then the pty is leaked.  In principle, we have 
> facilities to GC unused device nodes "eventually", although not a race-free 
> way to determine that no race occurs, assuming that we implemented that.  
> This leakage turns out to interact particularly poorly with our resource 
> limits on pty/pts pairs -- both the administrative limit imposed by sysctl 
> and also the functional limit on the number of entries in /etc/ttys.  It's 
> possible to imagine various sometimes messy techniques of performing this 
> garbage collection.

So this is the same issue I sent a message to arch_at_ about some time ago,
that /dev/ptmx already returns a reference to the new pty, already when
you stat(2) it (for example by running `ls -l /dev/ptmx')?

> Instead, what I'd like to do is modify the ptmx code to have a race-free 
> protocol, in which eventual termination of processes referencing the node 
> results in freeing of the nodes.  On some systems, ptmx performs a 
> "bait-and-switch", in which the file descriptor of the pty node is silently 
> substituted for the file descriptor of the ptmx code--similar to our model, 
> only no window between lookup and open, but also not easily supported in 
> our current VFS.  Another possibility is to introduce a new system call and 
> bypass ptmx entirely -- similar to pipe(), socketpair(), etc.

I actually think that this sounds pretty nice. You mean something like
an in-kernel implementation for openpty()?

Another thing that would make the TTY code a little bit cleaner in my
opinion is removing the PRIV_TTY_PRISON check and making something
generic inside devfs. If we have proper garbage collecting on TTY's,
then we can just change make_dev_cred() to bind the new device node to a
certain jail. That way you could even choose to hide nodes in /dev that
don't belong to the jail in question.

-- 
 Ed Schouten <ed_at_fxq.nl>
 WWW: http://g-rave.nl/