Date: Sat, 6 Jan 2007 22:36:51 +0100 From: Ed Schouten <ed@fxq.nl> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: freebsd-arch@freebsd.org Subject: Re: Request for PTY/devfs changes Message-ID: <20070106213651.GD46094@hoeg.nl> In-Reply-To: <10319.1168112909@critter.freebsd.dk> References: <20070106191401.GC8574@heave.ugcs.caltech.edu> <10319.1168112909@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
--FFoLq8A0u+X9iRU8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Poul-Henning Kamp <phk@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. >=20 > The leak obviously is a bug. >=20 > 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_PRISONOWNE= D. >=20 > Send patch :-) I'll do :-) --=20 Ed Schouten <ed@fxq.nl> WWW: http://g-rave.nl/ --FFoLq8A0u+X9iRU8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFoBZz52SDGA2eCwURAtuLAJ4j7UnP5nypwhdslW1TqcXZT2uAgACfWcrK E/BQcwI/xh3HUi9mX/hL3yc= =NlIm -----END PGP SIGNATURE----- --FFoLq8A0u+X9iRU8--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070106213651.GD46094>