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

[Andrew Findlay <[e-mail]>]

On Thu, Feb 12, 2015 at 12:53:00PM +0100, Michael Ströder wrote:

> 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 [e-mail] 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
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                [phone]     |
-----------------------------------------------------------------------