REPOST: Finding group members - fix to winbindd_ads.c

[Ken Cross]

Michael:

I don't disagree with anything you said.

However, we currently get different results from a getgrnam/getgrgid
depending on whether you "net rpc join" or "net ads join".  That, IMHO,
is a Bad Thing.

Thanks,
Ken


-----Original Message-----
From: Michael Steffens [mailto:michael.steffens at hp.com] 
Sent: Monday, February 10, 2003 7:20 AM
To: Ken Cross
Cc: 'Multiple recipients of list SAMBA-TECHNICAL'
Subject: Re: REPOST: Finding group members - fix to winbindd_ads.c


Ken Cross wrote:
> Currently, if you do WINBINDD_GETGRNAM to an NT domain using RPC, you 
> get *all* the members of a group, whether primary or supplemental.
> 
> The same call to an AD using LDAP just returns supplemental members.
> 
> My patch causes the call to either an NT domain or AD to return the 
> same thing.
> 
> There was some discussion about making it a separate call, but I think

> that'd be a mistake.  It seems like they should be consistent.

Would like to add my two cents to the discussion, too :)

I think there are good reasons for the habit of not including primary
group members in /etc/group, which would also apply to winbind
getgrnam/getgrgid calls.

Many (if not most) invocations of getgrnam/getgrgid are for
GID <-> name conversions, where the list of group members
is just unnecessary load. Which can be reduced by omitting primary group
members.

It's a pity there are no widespread standard Unix calls for these
conversions without querying group members, but that's a boundary
condition which winbind can hardly get around. Every "ls -l" gathers
group member lists just to ignore them, for example.

Furthermore, some platforms do have an implicit limitation
of group sizes, by providing a default fixed result buffer size, which
most callers of getgrnam/getgrgid (better: their reentrant counterparts
getgrnam_r/getgrgid_r) adhere to. Omitting primary members makes hitting
such limits less likely.

Cheers!
Michael