Date: Sun, 03 Jan 1999 14:09:16 -0700 From: Warner Losh <imp@village.org> To: freebsd-arch@FreeBSD.ORG Subject: Implementing a DEVFS daemon Message-ID: <199901032109.OAA57058@harmony.village.org>
next in thread | raw e-mail | index | archive | help
One idea that I've not seen talked about would be as follows. It is a variation on phk's /etc/dev.d discussions, but I think is simpler, more powerful and violates POLA less. Plus I'll offer a couple of examples of why I'd want devices to have persistent attributes. I do not assume that the underlying devfs actually supports persistence beyond the current boot. Consider having a daemon that saves the state of a particular /devfs tree. This daemon will wake up every now and again and read the /devfs tree. When it notices changes, it will record them in its database. This database will be in text format for easy editing. Then when the system starts up, it will use this database to set the permissions of devices as they arrive, if not initially present. This way to change the ownership of /dev/ttyd1, I say chown root.redheads /dev/ttyd1. The daemon notices after a short time and then for ever after when the system comes up /dev/ttyd1 is root.redheads as its devices. "for ever after" also includes when the device goes away for a while (say a modem pulled from the system to loan to a friend or a trip) but does not extend past other events that modify the device's attributes in a conflicting way (say I chgrp the device to losh-brothers). This gets the persisting part out of devfs and places it into a central daemon. This daemon would be the only one that would munge the devices' permissions after they appear, at least for devices that it knows about. No need to muck with mount, ifconfig, pccardd, etc to get things to work right. For devices that it doesn't know about, I can imagine that a useful extension would be a single script. /etc/device.conf (say) that would be executed with one argument (the node that was added to the tree). The shell script can then deal with setting default permissions. Should device classes be found to be desirable, then a simple c program could be used to ask a node in the /devfs tree what its device class is and then the shell script could use that information to set policy for that device. This would be simpler and easier than the daemon design that phk had talked about here. It would only add two files to /etc (device.conf and device.persist), rather than a tree and it would centralize administrative decisions for classes of devices. In addition, it would come very close to not violating POLA as the publish interface to setting and changing device permissions doesn't change and is consistent with other unixes. It would also be smaller, simpler and easier to write and easier to do a security audit on. The impact to the underlying devfs implementation is that it needs to honor chown, chmod, chgrp and symbolic links. It needn't worry about how things are persistent or not persistent. It just needs to manage trees of devices and allow symbolic links in that tree. It would also need to give the daemon the ability to ask if a node in the tree was a device or not, so would need to support stat(2) as well. I believe this is the minimal set of things needed. Also I assume that all devices are created by devfs either 000 or with the mode that the device tells devfs about, should it care to do so. I can think of many ways to optimize this to improve latency and reduce processing overhead, but for a first cut this would likely be unnecessary. Also, there is a "race" here. If I chmod 777 /dev/ttyd1 and then turn the machine off, it may or may not record that new mode. Re: Why have not information come back: I think that it is desirable to have permissions come back when you chmod 774 a device. If this device is a pc-card device, it won't exist when the system boots, but is added later by pccard. It might not even exist over several reboots of the machine, but when it does come back, I want the same permissions it had when it went away, just like things do today. I usually have a network card in my 1 pccard slot, but when I travel, I take the network card out and put a modem card in. I do not want to have to run my modem accessing programs as root or chown/chmod the device every time I stick it into the machine. Likewise, if I have a scanner on my SCSI bus that I don't always turn on, or share between many machines. When it goes away for a while and then comes back, I find it desirable to have the same view as it had before. I think the case of purchasing a single device, trying it out, then tossing it for months then buying another device months later is a much rarer case than the above cases and should require the exceptional activity rather than vice versa. Comments? Warner P.S. I'll be happy to put together a preliminary implementation of this daemon for people to play with. [It seemed appropriate to split this off from the initial thread. -EE] 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?199901032109.OAA57058>