HI!
I'm experimenting to replace slapo-memberof to slapo-dynlist in Æ-DIR's slapd.conf.
Ok, basically it works but...
Æ-DIR trys hard to follow need-to-know-principle. This means that memberOf values are only made visible to clients which they have defined to be visible on.
Thus I have ACLs like this and which don't work for these clients (lines wrapped):
access to dn.subtree="ou=ae-dir" filter="(objectClass=posixAccount)" attrs=memberOf val.regex="^.+$" [..] by set.expand="(user/-1 | user/aeSrvGroup | user/-1/aeProxyFor) & [ldap:///ou=ae-dir?entryDN?sub?(&(objectClass=aeSrvGroup)(aeStatus=0)(aeVisibleGroups=${v0}))]/entryDN" read [..] by * none
I'm aware that this is quite special. But is there any chance that something like this will be ever supported?
The alternative would be to implement an external update process for maintaining 'memberOf'. :-/
Ciao, Michael.
Michael Ströder wrote:
HI!
I'm experimenting to replace slapo-memberof to slapo-dynlist in Æ-DIR's slapd.conf.
Ok, basically it works but...
Æ-DIR trys hard to follow need-to-know-principle. This means that memberOf values are only made visible to clients which they have defined to be visible on.
Thus I have ACLs like this and which don't work for these clients (lines wrapped):
There's nothing dynlist is doing that would cause this ACL to break, if it worked before with slapo-memberof. In particular, by the time an ACL check is performed, the entire entry has been constructed, including the memberof attribute values. You're going to have to dig into this further on your own.
access to dn.subtree="ou=ae-dir" filter="(objectClass=posixAccount)" attrs=memberOf val.regex="^.+$" [..] by set.expand="(user/-1 | user/aeSrvGroup | user/-1/aeProxyFor) & [ldap:///ou=ae-dir?entryDN?sub?(&(objectClass=aeSrvGroup)(aeStatus=0)(aeVisibleGroups=${v0}))]/entryDN" read [..] by * none
I'm aware that this is quite special. But is there any chance that something like this will be ever supported?
The alternative would be to implement an external update process for maintaining 'memberOf'. :-/
Ciao, Michael.
On 2/14/22 23:39, Howard Chu wrote:
Michael Ströder wrote:
I'm experimenting to replace slapo-memberof to slapo-dynlist in Æ-DIR's slapd.conf.
Ok, basically it works but...
Thus I have ACLs like this and which don't work for these clients (lines wrapped):
There's nothing dynlist is doing that would cause this ACL to break, if it worked before with slapo-memberof.
Well, I appreciate you confirming that it's supposed to work, but it doesn't always work...
In particular, by the time an ACL check is performed, the entire entry has been constructed, including the memberof attribute values.
I should have noted that it's a search with filter (memberOf=..) which fails in cases where the set.expand <who> clause would grant the search access. Does that make a difference?
access to dn.subtree="ou=ae-dir" filter="(objectClass=posixAccount)" attrs=memberOf val.regex="^.+$" [..] by set.expand="(user/-1 | user/aeSrvGroup | user/-1/aeProxyFor) & [ldap:///ou=ae-dir?entryDN?sub?(&(objectClass=aeSrvGroup)(aeStatus=0)(aeVisibleGroups=${v0}))]/entryDN" read [..] by * none
Ciao, Michael.
On 2/14/2022 12:43 PM, Michael Ströder wrote:
Thus I have ACLs like this and which don't work for these clients (lines wrapped):
I'm not sure if you are asking whether the slapo-dynlist memberOf implementation supports ACLs in general, or specifically the type of ACL you are trying to use?
We are currently using the slapo-dynlist module for memberOf:
dynlist-attrset groupOfURLs memberURL member+memberOf@groupOfNames
and the following ACL appears to work properly:
access to dn.children="ou=user,dc=cpp,dc=edu" attrs=memberOf by self read by group.exact="cn=member-readers,ou=group,ou=service,dc=cpp,dc=edu" read by * none
openldap-technical@openldap.org
-
Howard Chu -
Michael Ströder -
Paul B. Henson