Full_Name: Matthew Backes Version: 2.3, 2.4 OS: all URL: Submission from: (NULL) (76.88.99.93) Set-acl who-clauses fail to match when accessing data through back-ldap and slapo-rwm. Given a local server with only the object: dn: cn=data,dc=local objectClass: organizationalPerson cn: data sn: sn data description: user where sn is an example attribute that we will protect: database bdb suffix "cn=data,dc=local" directory ./local checkpoint 1024 1 cachesize 10 index objectClass,dc,entryCSN,entryUUID eq index cn,sn,ou,title,description eq,sub access to dn.subtree="cn=data,dc=local" attrs=sn by set="user/title & this/description" write by * none access to dn.subtree="cn=data,dc=local" by * read So that any bound object with a title attribute matching the description attribute of the target should be able to see sn. Remote data: dn: dc=remote objectClass: organization objectClass: dcObject o: remote dc: remote dn: cn=user,dc=remote objectClass: organizationalPerson cn: user sn: user title: user userPassword: secret If we have the local slapd's back-ldap configured as: database ldap suffix "dc=remote" uri "ldap://127.0.0.1:2389" acl-bind bindmethod=simple binddn="cn=user,dc=remote" credentials=secret then everything works correctly. But if we remap the DN using slapo-rwm instead: database ldap suffix "dc=remote,dc=local" uri "ldap://127.0.0.1:2389" acl-bind bindmethod=simple binddn="cn=user,dc=remote" credentials=secret overlay rwm rwm-suffixmassage "dc=remote,dc=local" "dc=remote" Then the acl step fails: => access_allowed: read access to "cn=data,dc=local" "sn" requested => dn: [1] cn=data,dc=local => acl_get: [1] matched => acl_get: [1] attr sn access_allowed: no res from state (sn) => acl_mask: access to entry "cn=data,dc=local", attr "sn" requested => acl_mask: to value by "cn=user,dc=remote", (=0) <= check a_set_pat: user/title & this/description <= check a_dn_pat: * <= acl_mask: [2] applying none(=0) (stop) <= acl_mask: [2] mask: none(=0) => access_allowed: read access denied by none(=0) send_search_entry: conn 1 access to attribute sn, value #0 not allowed And the remote server was never queried for the title attribute.
mbackes@symas.com wrote: The reason is quite simple: set expansion uses the rewritten DN as the user's name, so a local lookup of the entry "cn=user,dc=remote" fails since no local database serves the naming context "dc=remote". The root cause is that back-ldap binds as the rewritten DN, which is later stored as the real identity. I think this was done on purpose, and is to some extent appropriate, but makes the type of ACL you want to design basically impossible. A solution would be to make slapo-rwm intercept successful binds (in the cleanup callback) and rewrite back the bound DN into the virtual naming context. I'll see if it is possible, but then we need to decide whether this is the desired behavior. Otherwise, we'd need to have two o_ndn fields: the real DN and the real-real DN. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando@sys-net.it -----------------------------------
ando@sys-net.it wrote: > mbackes@symas.com wrote: > > The reason is quite simple: set expansion uses the rewritten DN as the > user's name, so a local lookup of the entry "cn=user,dc=remote" fails > since no local database serves the naming context "dc=remote". The root > cause is that back-ldap binds as the rewritten DN, which is later stored > as the real identity. I think this was done on purpose, and is to some > extent appropriate, but makes the type of ACL you want to design > basically impossible. A solution would be to make slapo-rwm intercept > successful binds (in the cleanup callback) and rewrite back the bound DN > into the virtual naming context. I'll see if it is possible, but then > we need to decide whether this is the desired behavior. Otherwise, we'd > need to have two o_ndn fields: the real DN and the real-real DN. To further elaborate, even if the virtual DN is set instead of the real one in c_ndn, the operation fails because ACL checking passes through bi_entry_get_rw(), which is not provided by slapo-rwm, and can't be provided according to the current design, since it does not allow to massage the arguments. As a quick'n'dirty fix, what you can do is make the proxy database serve both naming contexts, namely database ldap suffix "dc=remote,dc=local" suffix "dc=remote" uri "ldap://127.0.0.1:2389" acl-bind bindmethod=simple binddn="cn=user,dc=remote" credentials=secret overlay rwm rwm-suffixmassage "dc=remote,dc=local" "dc=remote" This allows the proxy database to be found by select_backend() when searching the right backend using the real naming context. At the same time, internal searches occur as expected. This is a hack; the real fix requires to redesign the API of bi_entry_get_rw(), to let it modify the request arguments while letting the real function do the hard job. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando@sys-net.it -----------------------------------
> To further elaborate, even if the virtual DN is set instead of the > real one in c_ndn, the operation fails because ACL checking passes > through bi_entry_get_rw(), which is not provided by slapo-rwm, and > can't be provided according to the current design, since it does not > allow to massage the arguments. As a quick'n'dirty fix, what you > can do is make the proxy database serve both naming contexts, namely > > database ldap > suffix "dc=remote,dc=local" > suffix "dc=remote" This works for getting the query to the right place; thanks! Remapped attributes in the acl obviously don't work, but working around that is straight-forward also. > This is a hack; the real fix requires to redesign the API of > bi_entry_get_rw(), to let it modify the request arguments while > letting the real function do the hard job. Right, okay. Matthew Backes Symas Corporation mbackes@symas.com
changed notes
moved from Incoming to Software Bugs
Partial fix in HEAD, RE24
has workaround