Re: [ldapext] empty-groupOfNames-issue

[Simo Sorce <[e-mail]>]

On Fri, 2015-12-04 at 15:25 +0000, Andrew Findlay wrote:
> On Fri, Dec 04, 2015 at 03:11:22PM +0100, Michael Ströder wrote:
> 
> > Do you think that a complete replacement RFC _obsoleting_ RFC 4519 would be
> > needed?  If the ldapext community would agree on changing the standard wouldn't
> > a small RFC _updating_ RFC 4519 also be sufficient?
> 
> That may be possible, but I don't know enough about the conventions to
> be sure.
> 
> > Please let us keep the scope limited to the empty-groupOfNames-issue.  I'm not
> > keen on opening the can-of-worms on semantics of nested groups.
> 
> Indeed. That needs tackling in due course, but it is a much bigger problem.
> 
> > >> http://tools.ietf.org/html/draft-findlay-ldap-groupofentries
> > >>
> > >> + Very simple
> > >> + Fully compliant to standardization best practices
> > >>
> > >> - It's not clear whether it was widely adopted in deployments.
> > > 
> > > Maybe not in the exact form I described in that I-D, but functionally
> > > equivalent objectclasses have been in most of my customers' systems.
> > > It could be argued that the corrupted form of groupOfNames described
> > > above is actually proof of widespread deployment of an analogous class.
> > 
> > Hmm, the wording gets a bit blurry here.
> > How would you explain the clear distinction between 1. and 2.?
> 
> There are exacly 2 differences between groupOfNames and groupOfEntries:
> 
> 1)	the member attribute is mandatory in groupOfNames but
> 	optional in groupOfEntries
> 
> 2)	the name and OID are different
> 
> In practical terms, groupOfEntries is better because it allows for
> empty groups. The benefits are:
> 
> a)	Empty groups are reasonable things to have: the need for a group
> 	does not disappear just because there are no current members.
> 
> b)	Forcing groups to always contain at least one entry causes
> 	management systems to do silly things like adding an entry for
> 	a non-existent member or even making the group recursively a
> 	member of itself. These workarounds for the broken definition
> 	can cause security problems as well as just being awkward.
> 	There is no defined convention for doing this, so identifying
> 	the dummy member can be difficult. If several management systems
> 	can modify the same entry it is possible that it will accumulate
> 	several dummy members.
> 
> Changing the existing groupOfNames to make member an optional attribute
> does not solve the problem:
> 
> p)	Existing management systems will continue to add dummy members
> 	but new ones will not know what to do about such values.
> 
> q)	New management systems will have to check the schema definition
> 	to find out whether member is mandatory or not.
> 
> In effect, groupOfNames has been corrupted and is no longer a portable
> objectclass.

I do not agree with this conclusion.
Realxing the constraint from MUST to MAY is forward compatible, and
older tools can keep doing what they always did.

Given there is no provision in the old or new groupOfNames to have
members that "make sense", software always need to be prepared to deal
with bogus members, so p) is not a "problem to solve".

You may have a point with q) if you want to deal with a generic
management system, but then your proposal to create a new objectlcass
adds exactly the same problem, as the management system need to know
what to use, except it makes it worse in 2 ways:
1) you have no way to find out what to do just by inspecting the schema
because both classes may be in the schema, which do you choose ?
2) you have to change all client applications that are hardcoded to use
groupOfNames

Looking at 1) and 2) then q) is a comparatively little price to pay.

> On the other hand, the corrupt version of groupOfNames does serve as
> a proof that groupOfEntries is desired by the community because it is
> functionally identical.

Yet it is not identical, see 2) above.

Simo.

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