Re: [ldapext] empty-groupOfNames-issue

[Simo Sorce <[e-mail]>]

On Fri, 2015-12-04 at 10:56 -0500, Simo Sorce wrote:
> 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.

Just to be clear, I am not against groupOfEntries and necessarily in
favor of changing groupOfNames (although I did in our implementation), I
just wanted to express dissent on the conclusions you drew.

Simo.

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