If you don't want to read all the gorey details skip down to "* * * * *".
Following bug report #111946 and a number of issues with devfs I have decided that some serious changes are necessary to the way permissions for devices are managed. Here is the way it currently works: When I (or an auto-builder) build a devfsd package it creates a default /etc/devfs/perms file which contains the permissions of every device node in the system and every device node which is likely to be created (ideally it should be every device node possible but new devices are always being added). This file is currently created from the contents of /sbin/MAKEDEV by a complex script which translates mknod commands to permissions settings suitable for devfsd. Incidentally this creates another potential problem, where different auto-builders may build against different versions of makedev and have different config files, but this isn't an issue I even considered before writing this message... Now the output of this script refers to old-style names such as /dev/hda not the devfs names such as /dev/ide/host0/bus0/target0/lun0/disc (the devfs equivalent of /dev/hda), this is a problem because converting from the old names to the new names is not always possible (for example when you see /dev/sda you won't know which SCSI bus or LUN it is, different systems will therefore have different SCSI names for /dev/sda). This is a minor problem, a bigger problem is that when you have two IDE hard drives and an IDE cd-rom you won't know which of hda, hdb, and hdc is the cdrom! Now if everyone had sym-links for all devices this might still be managable (with a huge amount of pain and some support scripts to handle the case of IDE cd-rom vs IDE hard drive). However not everyone has "REGISTER .* MKOLDCOMPAT" in their config files so many people don't have compatibility links for all devices (I prefer to have as few compatibility links as possible on my systems - it's a matter of preferance). A further complicating factor is that the functionality of assigning permissions based on the compatibility names is a Debian-specific hack which the upstream author dislikes. So moving between Debian and non-Debian systems will be painful if you rely on this. Also due to the way the compatibility code works it is possible to have different permissions of a device after a restart of devfsd with no configuration changes having been made!!! So for example you are happily playing music from your CD-ROM and you decide to install/upgrade/remove lvm-common or tpctl (or one of the other packages that have devfsd configuration) and it will restart devfsd to read the configuration for it's device nodes, this could cause device nodes to get different permissions than they had on boot and make your CD-ROM unreadable to your music program!!! To solve this I have started developing the next version of the devfsd package in the following fashion: * * * * * Firstly I have taken the latest auto-generated permissions file as my starting point, from now on it will not be automatically generated and I will manually merge changes from /sbin/MAKEDEV periodically (or when I receive bug reports or notification from the makedev maintainer of significant new changes). I am changing the default perms file to use the new devfs names instead of the compatibility names in cases where there have been problems reported, in cases where I anticipate future issues, and for devices that I have on my own systems and can easily test which I think need to be changed. I would like to change it all to the new format, but this isn't going to be possible for some time. So it will have to be a gradual process continuing after the release of woody. Here are the choices that devfsd users have: 1) Continue to use their old setup and say "n" when asked whether /etc/devfs/perms should be replaced (NB you have to change /etc/devfs/perms before the upgrade to be given the choice). Then these changes will not affect you for better or for worse. 2) Check the new version when I put it in unstable and send me email about any devices you posess and have a good knowledge of which are in the old format and should be in the new format. Doing "ls -lR /dev" before and after the upgrade and checking for changes would be helpful (there will be changes, hopefully all will be desired). 3) Put devfsd on hold until it's all over. There are no serious bugs against devfsd at the moment and I don't expect to find any in the near future. I know this sucks very badly. But at the moment I can't think of a better solution to this situation (I am open to suggestions). It will be some time before I upload a package with the new changes, I will certainly wait until discussion on these lists has reached some sort of consensus. PS I have BCC'd this to the debian-user list to make people aware of what's going on, I didn't CC it because I think that any further discussion only belongs in private mail or on the debian-devel list. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
