Date: Tue, 27 Nov 2001 13:39:10 +0000 From: Brian Somers <brian@freebsd-services.com> To: Josef Karthauser <joe@tao.org.uk> Cc: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, mjacob@feral.com, arch@FreeBSD.ORG, brian@freebsd-services.com Subject: Re: Anybody working on devd? Message-ID: <200111271339.fARDdAU25756@hak.lan.Awfulhak.org> In-Reply-To: Message from Josef Karthauser <joe@tao.org.uk> of "Tue, 27 Nov 2001 11:41:33 GMT." <20011127114133.S643@tao.org.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Mon, Nov 26, 2001 at 10:25:06PM -0500, Garrett Wollman wrote:
> > In article <20011126230600$59b3@traf.lcs.mit.edu> you write:
> >=20
> > >It seems to me wrong to do 'adjustments'. Either you have a model that t=
> rusts
> > >drivers to do the right thing when the call make_dev, or you don't.
> >=20
> > My site policy about what permissions certain device nodes should have
> > should not, and in some cases probably cannot, be written directly
> > into a device driver. The driver should use the most conservative
> > possible settings -- in most cases, root:wheel/600 -- and let
> > user-land code apply whatever policy is desired. We already have
> > mechanisms for expressing some of that policy (e.g., /etc/fbtab) but
> > it's not cognizant of transient devices. That's part of the problem
> > which needs to be solved.
>
> Devices that come and go can come and go quickly. For instance a
> USB sync'd palmpilot only appears as a usb device once the hotsync
> button has been pressed, and disappears once the sync process has
> finished. A userland process that wants to sync has to wait until
> it sees the usb device node appear to know that it is there (unless
> usbd can fire the process off at enumeration time). If a userland
> process pokes with the node permissions sometime after the device
> node appears, there's a race between the application and the userland
> devd. Sometimes the sync will succeed, sometimes it will fail due
> to wrong dev node permissions.
>
> For this reason I'd prefer the devnode to be created with the right
> permissions in the first place. Phk was talking about loading
> user/group policies into the kernel so that make_dev can use them
> whilst creating the node.
One of the possibilities for solving the persistency problem that was
suggested at the Kernel Summit at Usenix this year was to simply keep
the data in a file underneath the devfs mount point.
A default set of permissions will be known about by the device driver
that does the make_dev(). If the user tells devfs to use different
permissions, they get stored in the file underneath the mount point
and simply override whatever make_dev() asks for.
You can subsequently umount the devfs and move/copy the file around
(this is good for creating chroot/jail environments).
At mount time, devfs validates the file. If it's garbage, the mount
fails.
I'd like if devfs *had* to be mounted on top of this file instead of
on a directory:
# mkdir /chroot
.... create chroot environment ....
# touch /chroot/dev
# ls -ld /chroot/dev
-rw------- 1 root wheel 0 Nov 27 13:14 /chroot/dev
# mount -t devfs devfs /chroot/dev
# ls -l /chroot/dev
crw-r--r-- 1 root operator 117, 0 Nov 26 19:13 acd0
lrwxr-xr-x 1 root wheel 5 Nov 26 19:13 acd0a -> acd0
lrwxr-xr-x 1 root wheel 5 Nov 26 19:13 acd0c -> acd0
crw-rw---- 1 root operator 152, 0 Nov 26 19:13 acpi
.....
crw------- 1 root wheel 12, 15 Nov 26 19:13 ttyvf
crw------- 1 root wheel 52, 0 Nov 27 13:20 tun0
crw------- 1 root wheel 52, 1 Nov 26 19:13 tun1
crw------- 1 root wheel 52, 2 Nov 26 19:13 tun2
crw------- 1 root wheel 52, 3 Nov 26 19:13 tun3
lrwxr-xr-x 1 root wheel 7 Nov 26 19:13 urandom -> random
.....
# chmod 664 /chroot/dev/tun0
# chmod 665 /chroot/dev/tun4
# umount /chroot/dev
# ls -l /chroot/dev
-rw------- 1 root wheel 2048 Nov 27 13:25 /chroot/dev
Of course doing this sort of thing is a bit of a PITA (take a look at
Solaris's namefs). It may be easier to have the mountpoint as a
directory and have a reserved file name for the persistency info, but
I don't think that's as orthogonal.
It could also be made possible to ``chmod -f'' and ``chown -f'' things
that don't exist (and won't be created by a clone handler like tun4 is
above) so that policy can be set for removable devices. It might also
be necessary to allow something like ``chmod -f 660 /dev/tun*'' and
for devfs to store this and apply it to matching devices as they are
make_dev()d.
I'm not sure how the policies should be listed - probably with a new
application.
--
Brian <brian@freebsd-services.com> <brian@Awfulhak.org>
http://www.freebsd-services.com/ <brian@[uk.]FreeBSD.org>
Don't _EVER_ lose your sense of humour ! <brian@[uk.]OpenBSD.org>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200111271339.fARDdAU25756>