registry team mailing list archive

[Bug Watch Updater <75602@xxxxxxxxxxxxxxxxxx>]

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.