Re: [ldapext] DBIS commentary

[Simo Sorce <[e-mail]>]

On Tue, 2015-12-01 at 09:52 -0800, Jordan Brown wrote:
> > I have people telling me groupOfNames doesn't work well for them
> > because it can be a group of anything.
> > Extra LDAP searches are required to figure out what type of object 
> > the members are.  That leads to a rather inefficient system.
> >
> 
> There are two problems there:
> 
> 1)  A group could contain anything, even when you want it to only
> contain one type.  Administrator error could lead to incorrect
> configurations.  In programming-ese, it's not type-safe.  One might
> hope that you could set up metadata limiting the types of objects that
> could be added to a group, like you can set up limits on the types of
> objects that can be put in a container, but I don't know if you can.
> One hopes that your administration UIs will help here - if you're
> defining a group of users, the administration UI presumably knows that
> and only lets you add users.  At the same time, this flexibility
> enables nested groups, which can be very useful.

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.

> 2)  You have to do "extra" searches to get any real information on the
> member.

The control above helps quite a bit in cases where you really need to
search.

>  Yes, that's a very big problem.  The particular pain point is that
> getgrnam and getgrgid are defined to return a list of the members of
> the group, necessitating a search for *each* member. That gets pretty
> painful when a group has thousands of members.

It is fully broken indeed, based on age old databases that were very
small and always local to the system.

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

>  The standards provide some help in that there are hints in the UNIX
> standard that the list of members returned may not be complete. 

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.

>  Also:  Caching is your friend. Note also that the PADL version of
> nss_ldap has a "nss_getgrent_skipmembers" option that disables
> returning the list of members.

Any client that doesn't do caching today is really a bad idea.

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


> Active Directory uses the same basic structure, but uses the "group"
> class instead of groupOfNames, and for "group" the "member" attribute
> is a MAY.  RFC2307bis-02 replaces groupOfNames with groupOfMembers,
> again with "member" as a MAY.
> 
> (One might have hoped that you could have an attribute with a empty
> list of values, but X.501 does not allow that.)
> 
> > See previous reservations regarding groupOfNames.  Imagine trying to
> construct a 
> > search
> > operation to find just host members, or just user members.
> 
> Do note that the queries that you normally need are "is this host (or
> user) a member of this group" and "what groups is this user a member
> of".  It's hard to find cases where you really want to ask "what are
> the members of this group".  The "is this X a member" and "what groups
> is this X a member of" queries aren't bad at all with groupOfNames -
> you have to do a lookup on X to get its DN, but then you 
> just do a natural (and efficient) search.

Yes this is generally the case for "system level" clients, but indeed
many poor administrative clients tend to do the former kind of query,
because they think it is a good idea to show all the members, they tend
to have some problems when the members reach the multiple tens of
thousands :-)

Simo.

P.S. I switched to use my "corporate" email address so there is no
confusion on what hat I may be wearing.

-- 
Simo Sorce * Red Hat, Inc * New York