Date: Sat, 02 Jan 1999 19:46:56 -0700 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: arch@freebsd.org Subject: Re: DEVFS, the time has come... Message-ID: <199901030254.TAA05638@pluto.plutotech.com> In-Reply-To: Your message of "Sat, 02 Jan 1999 11:36:45 %2B0100." <6040.915273405@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
> But if you think about chroot for a moment, it will be obvious to > you that we need a way to hide (whiteout) and to destroy for good > (unlink) a node. You would not want it to be possible to bring > them back in a chroot jail. Agreed, that could also be handled > by the same mount option which says "show me no new devices". Lets > bag this point as an implementation issue. It is not material to > the persistence/non-persistence debate. Actually it partially speaks to the persistence issue. Somewhere there is persistent data specifying that certain DEVFS instances have certain attributes. In other words, you haven't properly defined what persistent attributes are allowed in a 'non-persistent DEVFS' and what is not. >> From: Warner Losh <imp@village.org> >> >> What we absolutely must not do is to create devices that will cause >> the security of the system to be compromised. This would be >> absolutely disasterous from a PR point of view. > > Agreed. This is where I think a persistent DEVFS has a big problem > because old stuff will be kept around. We have no way of knowing > if a particular device is gone for good or will come back. And > we have no way to know, if it comes back, if the users considers > it the same device in the first place. You have the same problem if they decide to edit rc.devs and forget about it. You seem to have already acknowledged that the administrator must be able to control the policy of device permissions, and now we're just down to how that is achieved persistently (scripts, or daemon, or something else?). >> We must remember that rc.* is not an acceptible solution because >> devices can come and go. > > Devices which come and go will need a daemon anyway to swing them > into action (mount, ifconfig and so on). Which means having several programs read different configuration files detailing persistent attributes for device node permissions? I'd much rather push all such policy into one place than have to guess which of many potential culprits have munged my dev nodes. It also centralizes policy so that it can be easily audited. > I have deliberately kept this daemon out of the picture, because > it raises another bunch of sensitive issues and it does not depend > on the persistence or not of the underlying DEVFS. The underlying DEVFS does not need to be persistent. >> In another message I went over some of my security concerns, others >> have raised them as well. Basically, I don't want to see anything >> which would lessen the security of the system. > > This is an important point also for me, and it is where I am very > afraid of this dormant stuff in the persistence database. You cannot avoid this issue as persistence of some sort needs to be maintained somewhere. My solution to this is to centralize the policy so that it can be easily maintained and reviewed. >I would like to ask you all to refocus on the POLA part of the discussion >here, since all the other stuff you have raised all have technical (if in >some cases cumbersome) solutions for both kinds of DEVFS. Then perhaps we should refocus the discussion on the types of administrative policies for device nodes that we must allow. Once that is determined, our hand will be forced into a particular type of persistence implementation. My vote on this is that the administrator should be able to: 1) Rename/symlink device nodes (/dev/pass4 hardwired to the location of the systems scanner becomes /dev/scanner0, etc.) 2) Change the permissions and owner of arbitrary device nodes or classes of device nodes (/dev/sa0 is the 'public tape drive' but all other tape devices are reserved for system backups and can only be used by the admin). 3) Purge all persistence information for a particular instance easily, and selective purge persistence information with an operation as simple as editing a text file. 4) Use chmod, chgrp, ln, mv on dev nodes just as can be done today and have those operations persistently reported. 5) Express more complicated policies (including chmod, chown, ln -s, etc type operations) using a regular expression based syntax (/dev/r?sa[0-9].* have particular attributes). 6) Prevent new device node creation, modify new device default permission and whiteout behavior via mount options. > Obviously if we implement the daemon-assisted approach right away, > we could make it a switch if we wanted persistence, but I think that > would be asking for trouble BIG time. Then some systems would have it > and others not, and 3rd party developers would be screwed badly. The 3rd party developer would rely on the policy tools as shipped by the system. If the end user decides not to use those tools, it becomes the end-users problem (don't DO that!). > The question remains more or less: > > Do we want a "chmod 764 /dev/foo" to be persistent over reboot, > despite the significant amount of code it takes, and the potential > to pop out of the blue six months later and bite people ? Yes. > So far I hear the following clear opinion: > > Joerg: non-persistent > DavidG: non-persistent I don't think that either of their positions are that cut and dried. > Now, problems: Imagine a ZIP drive. Plugging it in is easy, and > it gets mounted and used. Now I unplug it. The device node cannot > disappear until it has been unmounted (last close) obviously, so > the device driver will have to send a signal to the devd process > saying "I'm toast", so that devd can umount (-force) which will > make the device node disappear (on last close). The device node disappears immediately for any potential new users. Anyone holding the device node open is redirected to deadfs so that they can receive EIO, etc. ad infinitum and the underlying device can safely clean up any per-instance data. There may be cases where you don't want the client to be redirected to deadfs before seeing EIO (perhaps you want to allow an ioctl to fetch state about the reason you are going away), but it should be possible to signal to devfs that no new lookups should find this node. Devices of this type would have to defer the creation of a replacement instance until the first one has fully cycled through last close, but this is a tractable problem (CAM does this right now). > So the "go away" event is NOT triggered by the disappearance of the > device node in /dev, that complicates matters a bit. The daemon should be able to see that the node has disappeared even if the FS accessing that device has not been unmounted yet. I seem to recall that umount doesn't require the device node in order to do its job. > As I said above, this doesn't really have any thing to do with the > persistence or not issue, so just consider this background info, and > lets not start a debate about this stuff yet. You will get your > chance on this stuff later on, don't worry :-) If you don't want us to talk about something, don't bring it up. This is especially true if you expect the moderator of a moderated list to limit the scope of the discussion. [There is only one case where I'll drop posts I feel are relevant and bring extra information to the choice at hand: If a strict policy for the thread has been stated in the initial message in the thread and the new posts don't fit that policy. IMO, dropping those posts otherwise would neither be fair to the readers of the list, not to the posters. -EE] -- Justin 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?199901030254.TAA05638>