Launchpad has imported 9 comments from the remote bug at http://bugs.freedesktop.org/show_bug.cgi?id=9328.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2006-12-13T04:40:03+00:00 Jonathan Anderson wrote: In my lab, there are lots of users in an LDAP database. These users are assigned to the groups audio,video,plugdev,etc. by pam_group (using the /etc/security/groups.conf file). The problem is, DBUS doesn't recognize users as being in groups unless they're in /etc/group, which isn't practical for our setup. So, there are permission problems with USB sticks, kpowersave, etc. (well, there *will* be, once I upgrade to a more recent KDE version). On my laptop, I can use (the kludge) "adduser $uname plugdev"... this won't work in the lab. Reply at: https://bugs.launchpad.net/dbus/+bug/75602/comments/0 ------------------------------------------------------------------------ On 2006-12-13T05:00:23+00:00 Hp-pobox wrote: dbus just uses the normal C library functions to get the user's groups; it isn't manually groping around in /etc/group or anything. Maybe you need to configure libc to use nscd or something like that? I don't know how to fix this on the dbus level, certainly dbus should not be in the business of understanding NIS, LDAP, PAM, /etc/group, and so forth by hand... Reply at: https://bugs.launchpad.net/dbus/+bug/75602/comments/1 ------------------------------------------------------------------------ On 2006-12-13T06:34:25+00:00 Jonathan Anderson wrote: Okay, so I did some digging in the DBUS source... I think that there are two problems, one libc-related, the other DBUS-related. The first is that getgrouplist() does not return "dynamic" groups assigned by pam_group. This is not a DBUS issue, so I guess it'll have to be a libc/PAM wishlist item. The second is that (if I'm reading this correctly) DBusUserDatabase *system_db is built when the daemon starts up, so it can only use static group assignments. If getgrouplist() were modified (or an alternative found), could DBUS be modified to allow group assignments to be "freshened"? Reply at: https://bugs.launchpad.net/dbus/+bug/75602/comments/2 ------------------------------------------------------------------------ On 2006-12-13T08:35:10+00:00 Hp-pobox wrote: There is a patch in CVS now that allows you to build in a mode where groups aren't cached. The problem is that if you're using the read-/etc-group libc implementation instead of nscd this will be absurdly performance-intensive. That is, every time someone sends a message over the bus we'd load and parse /etc/group and /etc/passwd. What we'd like someone to do is write a small test program to benchmark group- based bus security policy checks with and without caching the user/group information, and then run that benchmark a) with current caching b) with regular "read the file" libc implementation c) with nscd implementation Then we can discuss the right course of action. More discussion can be found in the mailing list archives. Reply at: https://bugs.launchpad.net/dbus/+bug/75602/comments/3 ------------------------------------------------------------------------ On 2007-10-27T15:21:33+00:00 Jerome-koumbit wrote: I haven't found much about this bug in the mailing list archive... Was a workaround found? Otherwise, has there been any progress on this front? Using Debian, I find it somewhat tedious to have to add every user to groups such as audio, plugdev and netdev in /etc/group on a multi-user desktop machine, to enable basic functionality like sound, automounting and network-manager access. Reply at: https://bugs.launchpad.net/dbus/+bug/75602/comments/6 ------------------------------------------------------------------------ On 2007-10-28T01:03:52+00:00 Hp-pobox wrote: I don't know of any progress. The situation last I knew remained that with /etc/group it is absurdly expensive not to cache the info from libc; with nscd, I'm not sure any profiling has been done. I don't know how the common distributions configure by default in recent versions. By hacking the dbus code you can trivially disable the caching of group information, but the question is just whether that will slow performance to a crawl. Remember the stuff dbus is doing happens for *every message* - it has to check what groups the user sending the message is in. Opening a file or making a blocking network request for every message will be too expensive. This may or may not be hard to fix, or may or may not even be a real problem with "normal" configurations shipped by distributions these days. All I really know for sure is that when originally implementing this feature (on some years-old Fedora or Red Hat flavor), the caching was necessary to avoid parsing /etc/groups over and over. So, what we need is research first of all. If it is still too slow to turn off the cache, perhaps a fix would be to expire the cache after some period of time. However I would not spend time on that without first just documenting the situation (what libc is doing, and how fast it is, in typical configurations). Reply at: https://bugs.launchpad.net/dbus/+bug/75602/comments/7 ------------------------------------------------------------------------ On 2008-01-20T12:54:36+00:00 Dariem Pérez Herrera wrote: I've configured an Ubuntu box to authenticate using Microsoft Active Directory through pam_winbind.so. Domain users can use pluggable devices through dbus/hal because I've used pam_group.so to assign such users to plugdev group. It worked just fine. Now I'm using Gentoo and I can't do the same, it's not working. Is it possible that some Ubuntu developer have solved the problem? My partial solution in Gentoo was to configure /etc/dbus-1/system.d/hal.conf to assign priviledges to group "domain users" and to modify /etc/init.d/dbus to start after samba/winbind. But there is a problem: any short-timed failure on network connection prevents dbus for knowing who are "domain users", so this users can't automount pluggable devices after any of these failures, they have to wait for my presence so I can restart dbus daemon, and consequently, all GNOME environment. I think this issue should be solved as soon as possible, because is fatal for remote authentication mechanism (LDAP, Kerberos, Active Directory) when network users can't use something as common as a pendrive. Reply at: https://bugs.launchpad.net/dbus/+bug/75602/comments/8 ------------------------------------------------------------------------ On 2009-11-27T01:52:07+00:00 ceg wrote: >From comment #6 i got the idea that /etc/group is cached and read only once during start up or simmilar. Would it be possible to refresh the cache when a request is made for a new user, that previously wasn't queried before? Or maybe only rely on chache for new users after some amount of seconds has passed without changes (due to session scripts). Reply at: https://bugs.launchpad.net/dbus/+bug/75602/comments/9 ------------------------------------------------------------------------ On 2009-11-30T07:44:11+00:00 Colin Walters wrote: Note applications should migrate to PolicyKit for privileged operations, and avoid using the DBus security policy. In the specific case of HAL, work is ongoing already to replace it. That all said, my guess is that the easiest fix here is to enable nscd and disable dbus' built in caching. (Maybe the latter could be a flag in the init script or we somehow detect nscd running) Reply at: https://bugs.launchpad.net/dbus/+bug/75602/comments/10 ** Changed in: dbus Importance: Unknown => High -- DBUS Should Support "Session Groups" (pam_group.so,/etc/security/groups.conf) https://bugs.launchpad.net/bugs/75602 You received this bug notification because you are a member of Registry Administrators, which is the registrant for D-Bus. _______________________________________________ Mailing list: https://launchpad.net/~registry Post to : [email protected] Unsubscribe : https://launchpad.net/~registry More help : https://help.launchpad.net/ListHelp
