Request for PTY/devfs changes

[Ed Schouten]

* Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
> >- Dev_clone event handlers cannot determine whether a LOOKUP or a CREATE
> >  is performed. When you create a small script that performs a stat() on
> >  /dev/ptyp0 to /dev/ptySv, you create a bunch of device nodes that
> >  aren't bound to a real pty controller (which leads to ucred 'leaks').
> >  Only invoking the event handler when a CREATE is performed simplifies
> >  the entire pty design, because we could immediately construct the pty
> >  structure. The pts code also suffers from this bug. A simple stat() on
> >  /dev/ptmx causes a pts to be created.
> 
> The leak obviously is a bug.
> 
> But only calling the handler on CREATE will not work, because plenty
> of programs will stat(2) first and find nothing there and complain
> to the user.

Is it really needed that we keep such compatibility? Shouldn't those
applications use grantpt(3) or pty(3) functions anyway?

We could find a solution in between that still fixes stat(2), if we want
to keep the compat. We could allocate a single dummy cdev in the SYSINIT
that gets returned with a LOOKUP. When a CREATE is performed, we
allocate a real cdev with actual contents. This causes /dev to only show
devicenodes of pty's that are actually in use. We should do something
like that with /dev/ptmx as well.

> It doesn't even work to send a "this if for a create" flag along
> for the dev_clone, because another process might race in and do
> something silly before we get to that level.

Sorry - I can't quite understand this. You mean a situation where two
threads perform an open() on the same filename at the same time could
cause two pty's to be allocated with the same name? But how is that
covered at this moment when two threads perform a stat() or open() at
the same time?

> >- Both the pty and pts source contain some small checks to make sure you
> >  can't open pty's from other jails. A downside of this approach is that
> >  you can see all the system's pty's in /dev. This is thus a small
> >  information leak. A nicer implementation that would even be more
> >  generic would be to add a flag to cdevsw's d_flags called D_PRISONOWNED.
> 
> Send patch :-)

I'll do :-)

-- 
 Ed Schouten <ed at fxq.nl>
 WWW: http://g-rave.nl/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20070106/b39d395d/attachment.pgp