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

[Simo Sorce <[e-mail]>]

On Tue, 2015-12-01 at 18:21 -0800, Jordan Brown wrote:
> [ 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?

The idea is that you can get all data up at once including objectclass
and then you can simply drop results that do not have the right
objectclass value.
It is a little more wasteful than being able to specify a secondary
filter (that would probably be a great addition to the draft), for the
search done on the attribute of the group entry, but it is still good
enough to efficiently get results as well as easily weed off unwanted
ones.

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

True, but are not doing this for security reasons, we are just taking
the fact that omissions are permissible as a blanket permission to omit
results, and clients should be prepared to deal with that.

After all the texts are vague and you could think that the security
measure expressed here is about not revealing group names.

The fact you can easily scan the whole group ID space is just the
annoying consequence of the fact most systems do not have a randomized
ID assignment policy and have a pretty limited ID space at just 32bit of
size or less. But hey, that's not my fault! :-)

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

Yes, it would be nice to change the class, because it is forward safe to
do so, if you created objects when the MUST was in place, nothing breaks
if you relax the constraint to MAY, at least from the POV of data
consistency in the directory.

And I never found any software the specifically rely on the fact you
can't delete the last member attribute from a group for something.
Actually usually I saw software that had to use workarounds like adding
the group dn to itself (and concealing the self-reference in the UI)
when an admin wants to remove the last member but not remove the whole
group.

Simo.

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