Request for PTY/devfs changes
Ed Schouten
ed at fxq.nl
Sat Jan 6 07:18:44 PST 2007
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/
-------------- 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-current/attachments/20070106/7a7d161c/attachment.pgp
More information about the freebsd-current
mailing list