Hi!
I had a problem with "empty groups": object class groupOfNames has a MUST member attribute, so you cannot create an empty group. I consider this to be a bug in the object class definition, specifically as groupOfNames is structural, and not auxillary. So in SLES empty (POSIX) groups are created with a namedObject structural class.
Unfortunately because of "structural object class modification from 'namedObject' to 'groupOfNames' not allowed", the entry has to be recreated whenever the first member is added or the last member is removed to/from a group.
While examining the problem,. I found out that the namedObject (rfc2307bis.schema) has ist "cn" attribute optional: ## namedObject is needed for groups without members objectclass ( 1.3.6.1.4.1.5322.13.1.1 NAME 'namedObject' SUP top STRUCTURAL MAY cn )
I'd consider this workaround as a bug also.
Two questions remaining:
1) is there a technical reason against empty groups? I'd consider them as valid as empty arrays.
2) Is it an LDAP requirement to forbid structural changes in object classes, or is it an implementation restriction? In my experience the ID of an entry is (if not the entry's UUID) more the value of DN rather than the structural objectClass...
Insights?
Regards, Ulrich
On Fri, 06 Dec 2013 09:49:45 +0100 "Ulrich Windl" Ulrich.Windl@rz.uni-regensburg.de wrote
I had a problem with "empty groups": object class groupOfNames has a MUST member attribute, so you cannot create an empty group. I consider this to be a bug in the object class definition, specifically as groupOfNames is structural, and not auxillary. So in SLES empty (POSIX) groups are created with a namedObject structural class.
You are not alone. You could try to restart the discussion on ietf-ldapext mailing list about
http://tools.ietf.org/html/draft-findlay-ldap-groupofentries
See Andrew's discussion start postings:
http://www.ietf.org/mail-archive/web/ldapext/current/msg01141.html
http://www.ietf.org/mail-archive/web/ldapext/current/msg01256.html
- is there a technical reason against empty groups? I'd consider them as
valid as empty arrays.
Let's go to ietf-ldapext mailing list for this discussion.
- Is it an LDAP requirement to forbid structural changes in object classes,
Yes. LDAPv3 prohibits to change the structural object class of an entry. I suspect this comes from restrictions due to checking DIT structure rules.
Ciao, Michael.
Ulrich Windl wrote:
Hi!
I had a problem with "empty groups":
You and everyone else in the world. A quick search would turn up hundreds of posts on this topic.
object class groupOfNames has a MUST
member attribute, so you cannot create an empty group. I consider this to be a bug in the object class definition, specifically as groupOfNames is structural, and not auxillary.
So in SLES empty (POSIX) groups are created with a namedObject structural class. > Unfortunately because of "structural object class modification from
'namedObject' to 'groupOfNames' not allowed", the entry has to be recreated whenever the first member is added or the last member is removed to/from a group.
While examining the problem,. I found out that the namedObject (rfc2307bis.schema) has ist "cn" attribute optional: ## namedObject is needed for groups without members objectclass ( 1.3.6.1.4.1.5322.13.1.1 NAME 'namedObject' SUP top STRUCTURAL MAY cn )
I'd consider this workaround as a bug also.
This is why we wrote a new version of rfc2307bis. http://tools.ietf.org/html/draft-howard-rfc2307bis-02
Two questions remaining:
- is there a technical reason against empty groups? I'd consider them as valid as empty arrays.
The groupOfNames definition comes from X.500. Ask the ITU what they were thinking.
- Is it an LDAP requirement to forbid structural changes in object
classes,
or is it an implementation restriction? In my experience the ID of an entry is (if not the entry's UUID) more the value of DN rather than the structural objectClass...
It is an X.500 requirement. Read the specs instead of asking what LDAP requires.
Insights?
Regards, Ulrich
The way I worked around this is to create new groups as groupOfNames with a single empty member: attribute. It's never caused any problems with any clients in my experience.
Do you use an existing member, or a non-existing dummy?
Liam Gretton liam.gretton@leicester.ac.uk schrieb am 09.12.2013 um 11:12 in
Nachricht 52A5979A.90708@leicester.ac.uk:
The way I worked around this is to create new groups as groupOfNames with a single empty member: attribute. It's never caused any problems with any clients in my experience.
-- Liam Gretton liam.gretton@le.ac.uk Systems Specialist http://www.le.ac.uk/its IT Services Tel: +44 (0)116 2522254 University of Leicester, University Road Leicestershire LE1 7RH, United Kingdom
On 09/12/2013 11:22, Ulrich Windl wrote:
Do you use an existing member, or a non-existing dummy?
Just a completely empty attribute, e.g.
dn: cn=physics,ou=group,dc=example,dc=org cn: physics gidNumber: 2000 objectClass: posixGroup objectClass: top objectClass: groupOfNames member:
On Mon, 09 Dec 2013 10:12:42 +0000 Liam Gretton liam.gretton@leicester.ac.uk wrote
The way I worked around this is to create new groups as groupOfNames with a single empty member: attribute. It's never caused any problems with any clients in my experience.
Yes, working around it with cn=dummy is possible. Take care of config of slapo-refint.
But it's bad practice if you want to have fine-grained constraints for 'member' to existing and active member entries.
Ciao, Michael.
openldap-technical@openldap.org
-
Howard Chu -
Liam Gretton -
Michael Ströder -
Ulrich Windl