On 2011-03-17 at 10:08, Tim Gustafson ( tjg@soe.ucsc.edu ) said:

Hi,

I'd like to let users create posixGroup objects, but I don't want them to be able to pick a gidNumber that is already in use, or that is less than 1000 or greater than 10000, and I only want the groups to be created in the ou=Group,dc=example,dc=com container.

Take a look at slapo-unique to enforce gidNumber uniqueness. Last part is definitely doable. As to enforcing a value to be within a certain range, I suppose if you can come up with a regex to match that, it should be possible.

We have something similar, in that users can create groups of the form <user>:<groupname>. Here are the ACLs that make that work:

# allow access to create entries under ou=group access to dn.exact="ou=group,dc=bx,dc=psu,dc=edu" attrs=children by users write by * read

# personal groups access to dn.regex="cn=(.+):.+,ou=group,dc=bx,dc=psu,dc=edu" filter=(|(objectclass=groupofnames)(objectclass=posixgroup)) attrs=member,memberUid by dn.regex="uid=$1,ou=people,dc=bx,dc=psu,dc=edu" write by dn.regex=".*/admin,ou=people,dc=bx,dc=psu,dc=edu" write by group.exact="cn=ldapadmin-groups,ou=group,dc=bx,dc=psu,dc=edu" write by * read --andy

to prevent gidNumber duplicates you probably need slapo-unique.

That works well; here's my configuration:

overlay unique unique_uri ldap:///ou=Group,dc=example?cn?sub? unique_uri ldap:///ou=Group,dc=example?gidNumber?sub?

ACLs along these lines should do the rest:

access to dn.exact="ou=group,dc=example" attrs=children by users write

access to dn.sub="ou=group,dc=example" attrs=entry filter="(&(objectClass=posixAccount)(gidNumber>=1000)(gidNumber<=1000)" by users add

I already have this:

access to dn.subtree="ou=Group,dc=example" attrs=manager,memberUid,description,myStatus,myComment by set="this/manager & user" write by * break

(My groups all have an additional objectClass, myGroup, which adds a manager, description, myStatus and myComment attribute to groups.)

Will the ACLs you propose break that? It doesn't look like they will; I just want to make sure.

Tim Gustafson Baskin School of Engineering UC Santa Cruz tjg@soe.ucsc.edu 831-459-5354

Am 18.03.2011 17:36, schrieb Tim Gustafson:

by set="this/manager & user" write

I'd use a 'dnattr' rule here instead of a set. Sets can have a severe impact on performance, since they are not cached.

If I take out the "filter" line, it works fine, but with the "filter" line there it doesn't work, regardless of what gidNumber I provide.

Yeah, I just tested myself. The problem isn't the filter in itself, but the greater-than and less-than operators. gidNumber doesn't have an ORDERING rule, so the filter will always return false. Since gidNumber is a builtin attribute, it can't be changed that easily, but I think recently saw an ITS that requested adding 'ORDERING integerOrderingMatch' to uidNumber and gidNumber. You'd have to wait for the next OpenLDAP version.

Regards, Christian Manal