Subject: [ldapext] Schema for posixGroup successor (RFC 2307 bis)

From: Michael Ströder <[email-masked]>
Date: Wed, 11 Feb 2015 10:58:31 +0100

HI!

Since Kurt expressed to follow very strict guide lines forbidding altering
existing NAMEs and OIDs of schema descriptions especially in RFC 2307 the
question is how to define a new object class for POSIX groups in RFC 2307bis

To preserve backwards compability I'd like to propose the following:

( <OID TBD>
  NAME 'posixGroup2'
  DESC '<TBD>'
  SUP ( groupOfEntries $ posixGroup )
  STRUCTURAL )

With this definition..

1. posixGroup2 would have 'member' and 'memberUID' both as optional attributes,

2. the object class still can be found with (objectClass=posixGroup) and

3. the object class is STRUCTURAL and therefore one can assign a specific DIT
content rule to it allowing to preclude either 'member' or 'memberUID' with
NOT to meet local system requirements.

4. there's no conflict on LDAP servers with the old RFC 2307 schema already added.

What do others think about this approach?

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Wed, 11 Feb 2015 12:24:40 +0100

Simo wrote:
> On Wed, 2015-02-11 at 10:58 +0100, Michael Ströder wrote:
> I'd call it posixGroupBis, but otherwise sounds like a good idea.

I have no strong opinion on the NAME.

> Does it have to be structural though ?

I expected this question. ;-)

Yes, it has to be STRUCTURAL and I already gave one rational with 3.  Note
that DIT content rules, which are very helpful for defining local profiles of
standard object classes, can only be assigned to STRUCTURAL object classes.
Also DIT structure rules and name forms only work with this kind of object
class.  And yes, I'm using all these schema elements. ;-)

> If it were an auxiliary I might be able to add it to a groupOfEntries
> object to turn it into a posix group at a later time, that would be
> nice.

Yes, I know. But please take note of Kurt's recent statements about IANA
considerations for NAME 'posixGroup' etc.
=> when using NAME posixGroup anywhere the object class must be STRUCTURAL

Ciao, Michael.

---

From: Simo Sorce <[email-masked]>
Date: Wed, 11 Feb 2015 06:29:30 -0500

> => when using NAME posixGroup anywhere the object class must be STRUCTURAL

Understood, all makes sense.

Simo.

---

From: Andrew Findlay <[email-masked]>
Date: Thu, 12 Feb 2015 10:27:38 +0000

>   SUP ( groupOfEntries $ posixGroup )

That's a very cunning plan, but I am not sure that it will work...

> 1. posixGroup2 would have 'member' and 'memberUID' both as optional attributes,

That depends on exactly how multiple inheritance works. The only
definition I have found so far is in RFC4512:

      An object class may be derived from two or more direct
      superclasses (superclasses not part of the same superclass chain).
      This feature of subclassing is termed multiple inheritance.

   Each object class identifies the set of attributes required to be
   present in entries belonging to the class and the set of attributes
   allowed to be present in entries belonging to the class.  As an entry
   of a class must meet the requirements of each class it belongs to, it
   can be said that an object class inherits the sets of allowed and
   required attributes from its superclasses.  A subclass can identify
   an attribute allowed by its superclass as being required.  If an
   attribute is a member of both sets, it is required to be present.

Thus I think that your new class would have *more* mandatory
attributes than either of its superiors:

	MUST ( member $ cn $ gidNumber )

Not quite the point as we really want member to be optional.

> 2. the object class still can be found with (objectClass=posixGroup) and

I like that bit!

> NOT to meet local system requirements.

+1

Looking through the common schemas it seems that multiple inheritance
is extremely rare, so I wonder whether all servers would even agree on
how it works...

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: Thu, 12 Feb 2015 12:17:43 +0100

>>   SUP ( groupOfEntries $ posixGroup )
           ^^^^^^^^^^^^^^
> [..]

Hey Andrew, *you* should really remember why you wrote
draft-findlay-ldap-groupofentries ! ;-]

Ok, you've overlooked that I wrote 'groupOfEntries' instead of 'groupOfNames'.

In draft-howard-rfc2307bis-02 'posixGroup' is declared as AUXILIARY, a change
which is forbidden according to Kurt's IANA rules.  And the draft contains a
declaration of 'groupOfMembers' which is pretty much the same as
'groupOfEntries'.  We will sort that out...

> is extremely rare, so I wonder whether all servers would even agree on

It works for me. :-)

Ok, it works in OpenLDAP since years.  We could send a poll ot ldapext and
ldapbis mailing lists which server products officially support multiple
inheritance.

Ciao, Michael.

---

From: Andrew Findlay <[email-masked]>
Date: Thu, 12 Feb 2015 11:48:07 +0000

> Ok, you've overlooked that I wrote 'groupOfEntries' instead of 'groupOfNames'.

oops... I had assumed you were going for a standalone definition, so I
did indeed misread it.

> 'groupOfEntries'.  We will sort that out...

Right. That is why I want to separate the groups work from any 2307
updates as far as possible.

> ldapbis mailing lists which server products officially support multiple

That would be useful. Are we agreed about how it *should* work?
My understanding is:

The new class has a set of MUST attributes that is the union of the
MUST attributes of the superior classes.
The new class has a set of MAY attributes that is the union of the
MAY attributes of the superior classes.
Any attribute that is MUST in one superior and MAY in another will
become MUST in the new class.

Andrew

---

From: Michael Ströder <[email-masked]>
Date: Thu, 12 Feb 2015 12:53:00 +0100

+1

Could you please go ahead pushing draft-findlay-ldap-groupofentries?

> become MUST in the new class.

That's exactly how I see it.

Ciao, Michael.

---

From: Ludovic Poitou <[email-masked]>
Date: Thu, 12 Feb 2015 13:26:05 +0100

I was trying to define the posixGroup2 object class in OpenDJ, and the server refuses it because we do not allow to define a structural objectClass that inherits from auxiliary objectClasses.

And this is the proper behavior as RFC4512, section 2.4.2 specifically calls it:

<quote>
 Structural object classes cannot subclass auxiliary object classes.
</quote>

Regards,

Ludo
-- 
Ludovic Poitou
http://ludopoitou.com

On 12 Feb 2015 at 12:53:17, Michael Ströder ([email-masked]) wrote:

+1  

Ciao, Michael.  

_______________________________________________  
Ldapext mailing list  
[email-masked]  
https://www.ietf.org/mailman/listinfo/ldapext

---

From: Michael Ströder <[email-masked]>
Date: Thu, 12 Feb 2015 13:30:53 +0100

Ludovic Poitou wrote:
> I was trying to define the posixGroup2 object class in OpenDJ, and the
> server refuses it because we do not allow to define a structural
> objectClass that inherits from auxiliary objectClasses.

Then you have a schema installed which is not pure RFC 2307!

Probably you already have a RFC2307bis-like schema workaround added which
violates Kurt's IANA guidelines.

> And this is the proper behavior as RFC4512, section 2.4.2 specifically calls it:

Yes, mixed inheritance of STRUCTURAL and AUXILIARY object classes is not allowed!

Ciao, Michael.

---

From: Ludovic Poitou <[email-masked]>
Date: Thu, 12 Feb 2015 13:33:05 +0100

Michael,

Yes, you’re right, I have RFC2307bis defined. Good point.

Ludo

-- 
Ludovic Poitou
http://ludopoitou.com

On 12 Feb 2015 at 13:31:05, Michael Ströder ([email-masked]) wrote:

Ciao, Michael.

---

From: Andrew Findlay <[email-masked]>
Date: Thu, 12 Feb 2015 12:54:36 +0000

> Could you please go ahead pushing draft-findlay-ldap-groupofentries?

OK. I won't have much time for this over the next month, but as a
start I attach the original draft and a summary of the discussions
surrounding it.

The draft itself is quite simple, in that it proposes a group class
that is very similar to the existing groupOfNames. The can of worms it
opened up is not so easy to fix however :-) The main issues relate to
nesting of groups: what it means, whether it should be allowed in a
given case, and how clients and servers might split the work in
dealing with potentially-nested groups. Some of the more likely
solutions to those problems would remove the 'member' attribute from
the groupOfEntries class, thus breaking your proposal...

Here is the discussion summary:
-----------------------------------------------------------------------
draft-findlay-ldap-groupofentries-00.txt discussion summary 2007-09-24
======================================================================

On September 17th I introduced an I-D to create an LDAP group class
that was capable of representing an empty group. The initial proposal
was for the smallest possible change from the existing groupOfNames
class.

Most people who joined the discussion on [email-masked] were broadly
in support of allowing empty groups, though some thought that any
changes away from the status quo were doomed to fail.

Howard Chu pointed out that groupOfUniqueNames is even worse than
groupOfNames as the LDAP syntax for the nameAndOptionalUID attribute
type cannot be parsed reliably.

Kurt Zeilenga provided much detailed editorial advice, and posed a
question about how to handle groups where the DSA is unwilling or
unable to return some or all member names.

Luke Howard suggested that the behaviour of nested groups should be
defined. I was initially against an explicit definition, but was soon
persuaded that there could be significant performance and security
problems with ad-hoc nesting. At this point the discussion moved
almost entirely to the consideration of nesting issues.

Pete Rowley wanted an interface to be used by read-only clients to find
out what groups a particular entry is a member of without caring about
how the groups are defined. He suggested a memberOf attribute (presumably
server-maintained) for this purpose. Michael Liben also liked this
approach.

Simo Sorce proposed a control for server-side group expansion, and
Michael Ströder suggested that an extended operation for asking specific
membership questions would be better. Howard Chu suggested that any such
operation would need a depth limit parameter.

Steven Legg proposed directMember and nestedGroups attributes, and
Michael Ströder suggested that these might be a sufficient set to
describe nested groups. I wondered whether nested groups should be split
into those that could in turn have their own nested groups and those
that could not, but Simo Sorce thought that people would never choose
to use the more restrictive case. I was initially against dropping the
original 'member' attribute, but Steven pointed out that having a new
directMember attribute would allow people to define their own group
classes and still take advantage of defined nesting semantics.

Current situation
=================

It seems to me that we now have these threads of development:

1)	A new structural group class that can represent empty groups.
	This could go forward with the existing ambiguous member
	attribute or it could become the basis of a group
	representation with more carefully defined semantics using
	directMember.

2)	A new auxiliary class and one or more attributes to represent
	groups that may contain other groups. For this to make much
	sense it would require the well-defined version of (1).
	
	In (1) and (2) I see the definitions of the attributes being
	the key, and would avoid requiring the use of the object
	classes to obtain the defined semantics.

3)	A new control or extended operation so that a client can ask
	the server to do the heavy lifting involved with nested
	groups.

4)	A new server-maintained attribute called memberOf to give an
	alternative way for clients to ask for membership information.
	AD already has such an attribute, and Pierangelo Masarati
	recently proposed one for OpenLDAP so there may be useful
	existing work to build on.

5)	A document explaining why groupOfUniqueNames,
	uniqueMember and nameAndOptionalUID are bad, possibly leading
	to them being deprecated in the next revision of the core LDAP
	standards.

I am willing to co-ordinate work on (1) and (2). Are there volunteers
to take on the others?

Andrew