Hi. I'm running an LDAP server where I auth my users against and use pam_group.so to add users to correct groups if they are infront of the machine. Even though I'm in the plugdev group I can't mount anything using gnome-volume-manager, I just receive a pop-up with the text Unable to mount volume Error org.freedesktop.DBus.Error.AccessDenied" "A securoty policy in place prevents this sender from sending this message to this recipient, see message bus configureation file (rejected message had interface "org.freedesktop.Hal.Device.Volume" member "Mount" error name "(unset)" destination "org.freedesktop.Hal") jonas@fry ~ $ id uid=1000(jonas) gid=100(users) grupper=18(audio),19(cdrom),27(video),100(users),1002(plugdev) Buf if I change the file /etc/dbus-1/system.d/hal.conf --- /etc/dbus-1/system.d/hal.conf.bak 2007-09-19 14:54:05.000000000 +0200 +++ /etc/dbus-1/system.d/hal.conf 2007-09-19 15:24:37.000000000 +0200 @@ -55,7 +55,7 @@ </policy> <!-- You can change this to a more suitable user, or make per-group --> - <policy user="0"> + <policy user="jonas"> <allow send_interface="org.freedesktop.Hal.Device.SystemPowerManagement"/> <allow send_interface="org.freedesktop.Hal.Device.VideoAdapterPM"/> <allow send_interface="org.freedesktop.Hal.Device.LaptopPanel"/> Without any restart or anything, it just starts to work. But if I try the same thing with a local user witch is added to the plugdev group in /etc/group it starts to work. So could this be a pam_group.so problem, well yes, but even though I remove the pam_group.so file from system-auth, and add my ldap user 'jonas' to plugdev group in /etc/group it still doesn't work, even after a reboot of the computer, just to be sure. I have read somewhere on other bugzillas, can't remember where that hald just reads /etc/group when starting and the user must exist in /etc/passwd. Here is ubuntu bug that might be related: https://bugs.launchpad.net/ubuntu/+source/gnome-volume-manager/+bug/67307 I can also say that I installed Ubuntu 7.01 with nss_ldap and pam_ldap, using pam_group.so it worked, and I can't see the difference. Reproducible: Always Steps to Reproduce: 1. Login as a user that exists only in ldap 2. Try to mount a USB stick in Gnome 3. Watch the Access denied pop-up Actual Results: access-denied Expected Results: A mounted USB-stick. I'm running unstable sys-auth/nss_ldap-257 due to this bug #162355.
Created attachment 131295 [details] emerge --info
I personally use LDAP at the office and my user does not exist in /etc/passwd but does exist in /etc/group and it works just fine. Run HAL from the console with verbose and daemonizing off and plug something in and post the log.
Reading further into your issue it's directly related to your usage of pam_group, putting the user directly in /etc/group should work. This basically has nothing to do with HAL and everything to do with D-Bus. Basically D-Bus has <policy group="plugdev">, so what happens is D-Bus calls getgrnam() and gets a list of the group members to see if the calling user is in that group. That function is handled by nsswitch. If you have your nsswitch setup correctly, it should first check /etc/group and then LDAP. Where it will find that the user is not in the plugdev group added by the HAL ebuild to /etc/group and then when querying LDAP it will not find a plugdev group so it will simply reject the message. If you read the man page for pam_group, when you use pam to look something up and to see if the user in in that group, pam_group will fake that the user is in /etc/group when reporting back. However, PAM is not involved here. NSS is involved. Essentially to do this correctly, you should add a plugdev group to LDAP and add all your users in there and the problem is solved. I understand what you're trying to enforce, every user can only be in the plugdev group on their machine. However, that's just not going to be possible. This is why the plugdev group is going away in favor of ConsoleKit in future HAL releases.
For some reason it started to work if I removed the pam_group.so and added the user to plugdev group in /etc/group. This hasn't worked before... *Sigh* Well thanks for the information.
