Re: problem with sets in 2.2.5 (not in 2.1.25)

[Giuseppe Milano <g.milano@reitek.com>]

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: [2]
=> dn: [3] cn=subschema
=> dn: [5] cn=default,dc=intesa,dc=it
=> dn: [6] ou=x2x,dc=intesa,dc=it
=> dnpat: [7] ^ou=(.+),ou=x2x,dc=intesa,dc=it nsub: 1
=> acl_get: [7] matched
=> acl_get: [7] 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
>>> dnNormalize:

=> ldap_bv2dn(cn=anastacia,ou=people,ou=all,ou=x2x,dc=intesa,dc=it,0) ldap_err2string <= ldap_bv2dn(cn=anastacia,ou=people,ou=all,ou=x2x,dc=intesa,dc=it)=0 Success => ldap_dn2bv(272) ldap_err2string <= ldap_dn2bv(cn=anastacia,ou=people,ou=all,ou=x2x,dc=intesa,dc=it)=0 Success <<< dnNormalize: => bdb_entry_get: ndn: "cn=anastacia,ou=people,ou=all,ou=x2x,dc=intesa,dc=it" => bdb_entry_get: oc: "(null)", at: "x2xTenant" bdb_dn2entry("cn=anastacia,ou=people,ou=all,ou=x2x,dc=intesa,dc=it") => bdb_entry_get: found entry: "cn=anastacia,ou=people,ou=all,ou=x2x,dc=intesa,dc=it" bdb_entry_get: rc=0 <= 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 : dn: cn=anastacia,ou=People,ou=all,ou=x2x,dc=intesa,dc=it x2xDomain: ACD canExecute: - objectClass: x2xPerson userPermission: 7c62425c-1359-478c-b147-9917ffed76c7 x2xDevice: anastacia x2xTenant: all cn: anastacia userPassword:: YW5hc3RhY2lh givenName: Anastacia sn: Anastacia executeAccessLevel: Default-Admin executeAccessLevel: Default-Supervisor executeAccessLevel: System groupAffiliation: Default groupAffiliation: Default-Supervisor readAccessLevel: 7c62425c-1359-478c-b147-9917ffed76c7 readAccessLevel: Default readAccessLevel: Management readAccessLevel: System canAddPeople: Yes writeAccessLevel: 7c62425c-1359-478c-b147-9917ffed76c7 writeAccessLevel: Default-Admin In version 2.1.25 the same condition works fine. Thanks to all Giuseppe Milano Reitek S.p.A. Giuseppe Milano wrote: Hi Kurt, 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. Thanks Software Developer Giuseppe Milano Reitek S.p.A. Kurt, 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 work anymore. 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 achieve something. 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. Greetings, ace