I've spent some time today investigating the hotplug device problem, and here are some notes. I believe I have found a working solution, but it need some more work.
In Debian/Etch, the local devices are accessed using hal over the dbus, and it is supposed to take care of access control. It is in the default Debian installation tracking group membership in the plugdev group to decide if a user get access to local devices or not. This do not scale. First of all one do not want to give all users access to all local devices on all machines. Next, it is not possible to put all users in that group and still get a responsive system. The traditional solution has been to add a pam module to add a user to groups within her login session, and thus grant access to only the machine where she is logged in, and only for processes forked from the login process. This no longer work as the hal/dbus process isn't aware of these added groups, as they are only visible for processes forked from the user login process, and hal/dbus is started when the machine boot. The hal/dbus system have a concept called at_console (see /etc/dbus-1/system.d/hal.conf), and those affected by that policy get the access we want. I've tracked this down to dbus checking "/var/run/console/<username>", and if it exist the user is considered at the console. There is nothing in Debian today creating this file. It is normally done by the pam_console pam module available in redhat from the pam-redhat package. In Debian there is, however, the libpam-foreground package creating /var/run/console/<username>:<console#>. There is also a patch in the Ubuntu version of dbus extending the check to also look for /var/run/console/<username>:*. I suggest we reuse this solution. I've added pam-foreground to the task list, and will add updated pam.d files to debian-edu-config. I will next upload a new version of dbus to the debian-edu repository, and hopefully this will fix the problem. Finally, we should get rid of the pam_group config granting group membership during login, as it no longer make sense to use. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
