Seems less likely to be a dbus issue than an OS issue. dbus just calls the C library routines ...

Kind of tough to debug for most dbus devs, since it involves ldap and debian and so forth.

I can reproduce the described problem when using local groups instead of LDAP groups.

How to reproduce:

(as root)

# for i in `seq 1 100`;do adduser --disable-password --gecos testuser$i test$i;done

# addgroup testgroup

# for i in `seq 1 100`;do addgroup test$1 testgroup; done

add testgroup to a policy for something (/etc/dbus-1/system.d/hal.conf) and when I restart dbus again I get the error:

Unknown group "testgroup" in message bus configuration file

So its not related to LDAP and because of the description on Gentoo (http://bugs.gentoo.org/show_bug.cgi?id=225895) its not related to Debian IMHO.

With more than 100 users in this case it always reproduceable.

Can you reproduce the problem with these 4 steps?

Thank you.

Looking at the code just now, maybe it's simple - dbus-sysdeps-util-unix.c:fill_group_info():

#ifdef HAVE_POSIX_GETPWNAM_R

    if (group_c_str)
      result = getgrnam_r (group_c_str, &g_str, buf, sizeof (buf),
                           &g);
    else
      result = getgrgid_r (gid, &g_str, buf, sizeof (buf),
                           &g);
#else
    g = getgrnam_r (group_c_str, &g_str, buf, sizeof (buf));
    result = 0;
#endif /* !HAVE_POSIX_GETPWNAM_R */
    if (result == 0 && g == &g_str)
      {
        return fill_user_info_from_group (g, info, error);
      }
    else
      {
        dbus_set_error (error, _dbus_error_from_errno (errno),
                        "Group %s unknown or failed to look it up\n",
                        group_c_str ? group_c_str : "???");
        return FALSE;
      }
  }

getgrnam_r() will fail and return ERANGE if the buffer is too small, as it probably is in this case.

:) fine. You will fix this problem/bug?

Or do you need anything else (from me)?

Thank you.

I probably won't get to this bug personally, but one of the more active dbus maintainers might, or anyone affected by it is welcome to submit a patch ;-)
In any case it's tracked here until someone patches it.

Created attachment 17838 [details] [review]
use sysconf to retrieve buffer size

Hi,

this an initial patch which I thought would have helped with the hardcoded buffer sizes, but reported said it didn't help.

Noèl, could you please update the VERBOSE run output with the patch applied?

Thanks,

Noèl, I'm tempted to agree with Havoc's comment that the issue might be with ERANGE handling.  Do you think you could gdb to this point and check whether ERANGE is effectively returned?

On my system (Fedora/glibc-2.8-3.x86_64):

os.sysconf('SC_GETGR_R_SIZE_MAX') => 1024

glibc bug?  Or maybe we need to avoid sysconf, and handle ERANGE and double the buffer size each time.

(In reply to comment #7)
> Noèl, I'm tempted to agree with Havoc's comment that the issue might be with
> ERANGE handling.  Do you think you could gdb to this point and check whether
> ERANGE is effectively returned?
> 

Will try on Tuesday.

I had some problems using gdb (no idea why), but hardwiring the output yielded that ERANGE is returned:

root@pindar:/tmp/dbus-1.2.1# sudo -u messagebus dbus-daemon --system
[...]
26349: No cache for groupname "testgroup"
26349: return value from getgr*_r: 34
Unknown group "testgroup" in message bus configuration file
No cache for groupname "testgroup"
[...]

I'll whip up a patch to increase the buf size until this succeeeds or a reasonable (512 KB?) limit is reached.

Marc

Sysconf support is clearly orthogonal now; on my system's man page, it's the recommended way to compute the buffer size, would it be useful to merge this sysconf support?  If yes, should I be filing a separate bug for this?

Well, done. With a bit of verbose test output (not in the patch), I get this:

[...]
10646: No cache for groupname "testgroup"
10646: Tried getgr*_r with buflen 1024, got result 34
10646: Tried getgr*_r with buflen 2048, got result 34
10646: Tried getgr*_r with buflen 4096, got result 0
[...]

Marc

Created attachment 17913 [details] [review]
Use sysconf to get initial buf size, then try exponential backoff if we get ERANGE

This patch is based on lool's work and probably works around a libc bug (it was no problem to get a group with enough users to exceed the announced 1024 byte limit, provided that one used a bugger big enough)

Small patch nitpick: would be good to consistently match the DBus code style which has a space between identifiers and parens; while (1) and not while(1), dbus_free (foo) and not dbus_free(foo) etc.

Other than that it looks good to me, if no one else adds any comments I'll tweak the style and commit in a day or two.

Ok, I modified this patch to fix a memory leak caught by "make check", removed spurious dbus_free(buf) calls that wouldn't compile in the non-recursive ifdef case, and tweaked the rest to fit the code style guidelines.

Thanks for the patch!

commit 9d51f086b05df196b94234d6a0d388594feedd73
Author: Marc Brockschmidt <he@debian.org>
Date:   Mon Jul 28 16:09:53 2008 -0400

    Bug 16727: Handle ERANGE for getgr; fixes user in many groups
    
    	Patch originally from Noèl Köthe.
    	Modified by Colin Walters <walters@verbum.org>
    
    	* dbus/dbus-sysdeps-unix.c, dbus/dbus-sysdeps-unix-utils.c:
    	Use a while() loop to reallocate buffer if we get ERANGE
    	return.  This fixes the case where a user is in a large
    	number of groups.