[ldapext] Using groupOfNames (or similar) for UNIX groups and netgroups (was Re: DBIS commentary)

[Jordan Brown <[e-mail]>]

[ Splitting off a subtopic as Michael requested. ]

On 12/1/2015 5:21 PM, Simo Sorce wrote:
> On Tue, 2015-12-01 at 09:52 -0800, Jordan Brown wrote:
>> There are two problems there:
>>
>> 1)  A group could contain anything, even when you want it to only
>> contain one type. [...]
> This is very true and there are products that can cope, there are also
> mechanism to more efficiently (at least latency wise) if you use
> controls like: https://tools.ietf.org/html/draft-masarati-ldap-deref-00
>
> Both OpenLDAP and 389ds (for FreeIPA) implement this control and we use
> it in various clients.

That control is indeed very interesting.  I don't immediately see how it helps 
with the type-safety problem, though.  Am I missing something?

>>   I think the truly right answer there is to add new APIs that don't
>> retrieve the members, and even to redefine the existing APIs to not
>> retrieve the members, because there are almost no cases where it
>> actually makes sense to retrieve the list of members of a UNIX group.
> It would be nice to have a new API, although Posix has some wiggle room
> which we fully exploit in clients like Windbind and SSSD.
>
> Both clients simply do not return all members in the enumeration cases
> (getgrent) but only in the explicit group retrieve case (getgrnam).
> This is because Posix allows to omit results in the enumeration case
> according to some interpretations.

Yes, and I infer that there's corresponding omissions in other parts of the 
standard.  In the getgrent description, the standard describes omitting this 
information on the basis of security restrictions. Omitting the data there would 
not help security at all if you could immediately turn around and request it 
through getgrname and getgrgid.  Meeting the security need would require having 
the restrictions in both places.

> Indeed, some admins complain about this so switches are provided in the above 
> mentioned clients to behave "the classic way". And surprisingly very few systems 
> really have a big issue with this. Given that any application that depends on 
> full group enumeration is already fully broken and a performance liability on 
> any enterprise system that has accounts in the thousands. 

Right.  The old "walk through all of the groups and then through all of their 
members" strategy is doubly wrong:  the number of groups can be very large, and 
the number of members of each group can be very large.

Heck, even with RFC2307 memberUid groups, simply retrieving the group list can 
easily involve moving half a megabyte of data. That's a lot of wasted processing 
when all you really wanted was a gid<->name lookup.

>> As long as we're talking about flaws in groupOfNames:  there's also
>> the problem that "member" is a MUST attribute, and that makes empty
>> groups problematic.
> This was, in fact, such a big problem that in the FreeIPA product we
> decided to break with the standard and changed member to be MAY, never
> looked back on this choice.

We could address it through introducing a new object class (and here I include 
just grabbing "group" from AD or "groupOfNames" from RFC2307bis-02, not just 
creating a wholly new one), or by changing the definition.  This is one of those 
cases where I'd say that breaking formal compatibility might well be appropriate.