devfsd changes
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
Reply to: