Re: [ldapext] empty-groupOfNames-issue

[Andrew Findlay <[e-mail]>]

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.

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.

Andrew
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                [phone]     |
-----------------------------------------------------------------------