tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: FreeBSD devfs support on NetBSD 5.0

At Mon, 22 Jun 2009 13:13:08 -0400 (EDT), der Mouse 
<mouse%Rodents-Montreal.ORG@localhost> wrote:
Subject: Re: FreeBSD devfs support on NetBSD 5.0
> > [...], but if you do want to see new devices pop up in a chroot area
> > then you need to come up with a new security model because your
> > current one is broken by its design :-))
> Hardly.  You're assuming chroots are used only for jailing things like
> NTP.

I meant only in a chroot area where you are in fact trying to limit
visibility to some devices but not others -- though I did have in the
back of my mind that one might allow partial mounts of sub-trees of
devfs, such as just /dev/usb0 or similar.

>  That's far from its only use; for example, I've used chroots for
> "play areas", areas whwere I can, for example, test a "build and
> isntall of the world" without risking my current system.  In an
> environment like that, I pretty much want /dev to be as much like the
> real thing as feasiable.

so, don't mount it read-only if you don't want it mounted read-only!  :-)

> The major thing I think this needs is a union layer that doesn't copy
> up on changes, but rather applies modifications to what's in the lower
> layer.  In particular, something like "chmod 666 /dev/uk0" needs to
> result in uk0 being left in the lower layer in all respects but
> permissions, rather than an upper-layer vnode being created which
> completely hides the lower-layer one.  This is necessary to make things
> disappear correctly on detach....

Yes, that's along the lines of what I was getting at I think.

Perhaps ideally the changed metadata in the upper layer is preserved
regardless of whether or not the device disappears for a time in the
devfs layer so that it re-appears with the desired permissions and/or

This is where I was having my quandary about whether or not to support
rename(2) (and to some extent unlink(2) as well) -- to do so will
require creation of a hard-link in the upper layer (and corresponding
white-out file) that is going to still referencing the original filename
in the lower layer.  I think this may work with the current unionfs
rename(2) support, but I haven't looked into it in detail.

Personally this is all getting a little beyond what I would consider for
my own primary requirements for a dynamic devfs.  I'd quite happy with
just the basic devfs as long as I could use something like kqueue(2) to
watch directories of devfs for events where device files might appear
and disappear.  I'm quite happy to have a script at boot, and a daemon
watching for devices to come and go, to manage localised permissions and
ownership requirements.

                                                Greg A. Woods
                                                Planix, Inc.

<>       +1 416 218-0099

Attachment: pgp9bI9HFF0qu.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index