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
ownership.
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.
<woods%planix.com@localhost> +1 416 218-0099 http://www.planix.com/
Attachment:
pgp9bI9HFF0qu.pgp
Description: PGP signature