[Date Prev][Date Next]
Re: problem with sets in 2.2.5 (not in 2.1.25)
Hi to all,
Ok, ACL SETS seems to work fine in normal conditions but i can't understand why in some cases they differ form older versions of openldap.
For example I can't understand why acl and sets fail in this condition:
My ACL is:
access to dn.regex="^ou=(.+),ou=x2x,dc=intesa,dc=it"
by users set=(user/x2xTenant&[$1]) read
when i search for "ou=all,ou=x2x,dc=intesa,dc=it" with user "cn=anastacia,ou=People,ou=all,ou=x2x,dc=intesa,dc=it" no entry was returned.
The slapd log is:
=> access_allowed: read access to "ou=all,ou=x2x,dc=intesa,dc=it" "entry" requested
=> dn: 
=> dn:  cn=subschema
=> dn:  cn=default,dc=intesa,dc=it
=> dn:  ou=x2x,dc=intesa,dc=it
=> dnpat:  ^ou=(.+),ou=x2x,dc=intesa,dc=it nsub: 1
=> acl_get:  matched
=> acl_get:  attr entry
=> acl_mask: access to entry "ou=all,ou=x2x,dc=intesa,dc=it", attr "entry" requested
=> acl_mask: to all values by "cn=anastacia,ou=people,ou=all,ou=x2x,dc=intesa,dc=it", (=n)
<= check a_dn_pat: users
<= ldap_bv2dn(cn=anastacia,ou=people,ou=all,ou=x2x,dc=intesa,dc=it)=0 Success
<= ldap_dn2bv(cn=anastacia,ou=people,ou=all,ou=x2x,dc=intesa,dc=it)=0 Success
=> bdb_entry_get: ndn: "cn=anastacia,ou=people,ou=all,ou=x2x,dc=intesa,dc=it"
=> bdb_entry_get: oc: "(null)", at: "x2xTenant"
=> bdb_entry_get: found entry: "cn=anastacia,ou=people,ou=all,ou=x2x,dc=intesa,dc=it"
<= acl_mask: no more clauses, returning =n (stop)
=> access_allowed: read access denied by =n
I don't understand why it reads "null" as x2xTenant from user configuration when the ldif of the user is :
In version 2.1.25 the same condition works fine.
Thanks to all
Giuseppe Milano wrote:
I've experienced the same trouble with SETS switching from 2.1.25 to 2.2.23.
I use SETS to decide which entry a user can see an which he can modify. This is decided by matching attribute values of user and entry for which the user wants read/write privileges
Here is an example of my ACLS that use SETS clause on openldap 2.1.25:
access to attr=canExecute
by self read
by users set=(this/executeAccessLevel&user/groupAffiliation) read
by users set=(this/executeAccessLevel&user/userPermission) read
by users set=(this/executeAccessLevel&[Everyone]) read
I've found very userful your article in Faq-O-Matic.
I can't find other information about the SETS clause not working in newer versions of openldap.
So what I'd like to ask is if you or someone else has found a solution to use SETS in the newer versions of openldap.
I experieced trouble switching (also called 'upgrading') from 2.1.25 (stable)
to 2.2.5 (release).
In 2.1.25 the use of 'set' in ACL seems well supported, please note my article
in the Faq-O-Matig about that.
When I switched to 2.2.5, this feature didn't seem to work anymore.
So, I switched back, and it worked again. And back to 2.2.5, and they didn't
Has something changed in 2.2.5 regarding sets in ACL's ?
Some other experiences I had:
a. 2.2.5 uses new schema's that are incompatible with 2.1.25 and vice versa. I
am only using core.schema, cosine.schema and nis.schema. Of course the new
schema's are in the distribution.
b. (OT) qmail.schema needs to be patched to work with 2.2.5. However, that new
schema is compatible with 2.1.25. You can find the patch in the archives of
the qmail-ldap list at www.qmail-ldap.org
c. I am now using BDB 4.2.52 with the two patches applied. I use the
non-strong-crypto version. When I switch to 2.2.5, I can't use my existing
database anymore. db_recover doesn't help. I deleted the database and build
it from scratch, through the interface I am now building (qwido, as you all
know by now). That worked fine up to a certain level where I use ACL 'set' to
When I switched back to 2.1.25, apart from restoring the 2.1.25 schema's, also
the database didn't work anymore. I repeated the procedure, which is, I
chucked the database, started building it from scracth throug the interface,
and of course now 'untill the end' since sets where working again.
When I switched back to 2.2.5, again the same database problem.
Of course I can reproduce this and send logfiles, if that is needed.