REPOST: Finding group members - fix to winbindd_ads.c

[Michael Steffens]

Hello Ken,

Ken Cross wrote:
> 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.

Agreed 100%, too! :)

Wrote this because from previous postings I had the impressions that
most people are voting for unifying to inclusion of primary group members,
who also had their valid points.

But I think this way is not necessarily a good idea. Unifying the
behaviour *is* a good idea, for sure. :)

Cheers!
Michael


> -----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