Request for PTY/devfs changes

Hello everyone,

A few days ago I started to toy around with FreeBSD 7.x and jails with
unionfs. After a few hours I got to know the dreaded 'zombie jail' bug
(PR kern/89528). I've been reading a lot of kernel source the last few
days and I think I now understand a lot of existing problems in the
current code.

There are a couple of bugs in the FreeBSD kernel that aren't hard to
cure, but will lead to a better PTY implementation:

- 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.

- 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.

  When this flag is set, lookup()'s and readdir()'s inside a jail don't
  return objects that don't have the same prison as the caller. open()
  should have a small check to disallow access outside the jail and when
  not root. PRIV_TTY_PRISON could then be renamed to PRIV_DEVFS_PRISON.
  When the D_PRISONOWNED flag is unset, make_dev_credv() should make
  sure cr_prison inside cdev's si_cred is unset to prevent prison leaks.

When both changes are implemented, the pty/pts code itself could be
changed to be a lot more simple. I would love to send in the patches,
but I first like to hear your opinions on this subject. Are my findings
correct? If not, why?

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