Subject: [ldapext] empty-groupOfNames-issue

From: Michael Ströder <[email-masked]>
Date: Fri, 4 Dec 2015 12:17:49 +0100

HI!

I try to summarize the pros and cons of approaches dealing with the
empty-groupOfNames-issue raised here and there very often.

Let us please focus on this particular issue.

-------------------------------------------------------------------------

1. Modified standard schema descriptions for 'groupOfNames' and
'groupOfUniqueNames':

This is the work-around already chosen by various vendors:
The MUST member or MUST uniqueMember is turned into MAY.

+ it just works, no interop-problems seen so far.
+ no change required in LDAP clients
+ no change required in access control rules
+ no change required in other client or server-side code dealing with groups

- It violates standardization best practices, most notably IANA considerations.
- It could serve as a bad example to change standard schema at will.
-

Hopefully Rolf Sonneveld and Andrew Findlay will clearly comment on IANA
considerations.

-------------------------------------------------------------------------

2. new object class 'groupOfEntries'

Andrew kindly wrote an mini I-D defining a new structural object class
'groupOfEntries' simply with MAY member instead of MUST meant as direct
replacement for 'groupOfNames'.

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.
- small change required in LDAP clients for searching group entries
- small change required in access control rules
- small changes required in other client or server-side code dealing with groups

-------------------------------------------------------------------------

3. draft-brooks-ldap-sets

More general approach for solving all kinds of grouping issues by providing a
generic schema for sets.

http://typinganimal.net/rants/textify.php?f=draft-brooks-ldap-sets-00.txt

+ generic solution for everything

- completely new approach not compatible at all to what clients expect today
- access control rules have to be modified (which might also be a pro but not sure)
- I-D did not receive much review so far, review effort needed

-------------------------------------------------------------------------

Add more variants if you know about them.

I'd like to get some result soon on which of these solutions have a vague chance
to be adopted at all.  Given the former discussions we likely achieve a quicker
result if we simply rule out approaches first.

Especially some vendors should raise their voice which approaches they are
willing to adopt or not.

Ciao, Michael.

---

From: Andrew Findlay <[email-masked]>
Date: Fri, 4 Dec 2015 13:47:57 +0000

> Hopefully Rolf Sonneveld and Andrew Findlay will clearly comment on IANA

I don't think there is an IANA consideration here. The modified schema
is (currently) incorrect according to RFC4519 or is alternatively an
experiment leading to a proposed change to a standard. In the latter
case it would have to be accepted by IETF and published in a new RFC
that obsoletes 4519. At that time, IANA would update the reference in
the Object Identifiers table to point to the new document but would have
no other involvement.

In practice I cannot see such a change ever being accepted into the
standards track. If anything, the relatively wide distribution of
non-conformant implementations makes a stronger case for deprecating
these objectclasses for new deployments.

The definition of groupOfNames goes right back to X.521(1988) and it was
already broken at that point:

a)	member was a mandatory attribute

b)	Nested groups were mentioned in the text but the semantics
	were left undefined

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.

> - small changes required in other client or server-side code dealing with groups

Andrew
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------

---

From: Michael Ströder <[email-masked]>
Date: Fri, 4 Dec 2015 15:11:22 +0100

> the Object Identifiers table to point to the new document but would have

Ok.

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?

> a)	member was a mandatory attribute

Hmm, I somewhat disagree here.  But maybe I'm just too pragmatic. ;-)

> b)	Nested groups were mentioned in the text but the semantics

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.

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

Ciao, Michael.

---

From: Andrew Findlay <[email-masked]>
Date: Fri, 4 Dec 2015 15:25:10 +0000

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

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

> 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: Simo Sorce <[email-masked]>
Date: Fri, 04 Dec 2015 10:44:47 -0500

> above is actually proof of widespread deployment of an analogous class.

My 2c:
An auxiliary class may be a better choice for a standard.

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

---

From: Simo Sorce <[email-masked]>
Date: Fri, 04 Dec 2015 10:56:44 -0500

> In effect, groupOfNames has been corrupted and is no longer a portable

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.

> a proof that groupOfEntries is desired by the community because it is

Yet it is not identical, see 2) above.

Simo.

---

From: Simo Sorce <[email-masked]>
Date: Fri, 04 Dec 2015 10:57:58 -0500

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

---

From: Andrew Findlay <[email-masked]>
Date: Fri, 4 Dec 2015 16:34:29 +0000

> An auxiliary class may be a better choice for a standard.

Yes: I also prefer to define aux classes where possible.
groupOfEntries was defined STRUCTURAL to make it a drop-in
replacement for groupOfNames.

If we were starting from a clean slate we might just define:

     ( 1.2.826.0.1.3458854.2.1.1.666 NAME 'membershipObject'
            SUP top
            AUXILIARY
            MAY ( member )
     )

and allow designers to apply it to any appropriate structural class.
Following that to its logical conclusion would give almost 1:1
correspondence between objectclasses and attributetypes, which most
would probably regard as over-normalisation!

In fact I think groups are very reasonable STRUCTURAL objects,
as the concept of groups has such broad application. Where I might argue
with the current definition of groupOfNames/groupOfEntries is the list
of other descriptive attributes (why should groups have a
businessCategory but no displayName for example?)

Andrew

---

From: Michael Ströder <[email-masked]>
Date: Fri, 4 Dec 2015 17:47:04 +0100

> Yet it is not identical, see 2) above.

I concur with Simo: The issues are almost non-issues because applications
already have to deal with the non-standard variants today.

Also in practice I see much less client applications capable to properly add
dummy 'member' values, and if they do you have to explicitly configure it anyway.

The only soft issue is that changing 'groupOfNames', after careful
considerations of course, could be abused as an example to request more
quick&dirty changes in standardized schema (probably without careful
considerations).

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Fri, 4 Dec 2015 17:55:29 +0100

> Yes: I also prefer to define aux classes where possible.

Note that DIT content rules (DCRs), DIT structure rules and name forms can only
be defined for structural object classes.

=> I prefer to have a structural object class for group entries.

With those rules you can define a local profile for structural object classes.
E.g. I make heavy use of DCRs with NOT to prevent lazy people from abusing
attributes for any blurb breaking semantics.

Having said this:
If we change the structural object class 'groupOfNames' to MAY member,
backward-compability can be easily achieved by locally adding MUST member to a
accompanying DIT content rule (on LDAP servers supporting DCRs). :-)

Ciao, Michael.

---

From: Simo Sorce <[email-masked]>
Date: Fri, 04 Dec 2015 12:22:56 -0500

> businessCategory but no displayName for example?)

I tend to agree, but posixGroup is structural ... sigh :)

Simo.

---

From: Jordan Brown <[email-masked]>
Date: Fri, 4 Dec 2015 11:15:48 -0800

> Especially some vendors should raise their voice which approaches they are

I believe that the existing Solaris code (in S11+) will work with minor 
customization with any groupOfNames variant.  You'd just tell it what object class 
and attribute to use.

Anything with a fundamentally different structure... it'd be tough. The incentive 
to implement a new standard that the customers haven't adopted, that doesn't 
provide much truly new functionality, is pretty low.  (Yes, I know that's a Catch-22.)