Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 06 Jan 2007 19:48:29 +0000
From:      "Poul-Henning Kamp" <phk@phk.freebsd.dk>
To:        Jonathan Dama <jon@ugcs.caltech.edu>
Cc:        Ed Schouten <ed@fxq.nl>, freebsd-arch@freebsd.org
Subject:   Re: [ed@fxq.nl: Request for PTY/devfs changes] 
Message-ID:  <10319.1168112909@critter.freebsd.dk>
In-Reply-To: Your message of "Sat, 06 Jan 2007 11:14:01 PST." <20070106191401.GC8574@heave.ugcs.caltech.edu> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <20070106191401.GC8574@heave.ugcs.caltech.edu>, Jonathan Dama writes
:

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

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.

>- 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 :-)

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?10319.1168112909>