If you create a deny ACI for some or more attributes there is incorrect behaviour as you cannot rename the entry anymore. Consider the following example (no linked attributes neccesary)
ou=Tenants,dc=example,dc=com with the following 2 ACIs (targetattr = "*")(version 3.0; acl "admin"; allow(all) userdn = "ldap:///uid=abc,ou=people,dc=example,dc=com";) (targetattr = "l")(version 3.0; acl "deny-write-linkedattributes"; deny (write)(userdn = "ldap:///all");)
Authenticate as user uid=abc,ou=peole,dc=example,dc=com (so not as the directory manager, you need someone within the directory!) Create an inetOrgperson object with just cn (=rdn) and sn under ou=Tenants. Try to modify the RDN of the entry and you get:
Error 50 insufficient access rights.
The deny aci does not necessarily have to be for an attribute present in the entry, or even be for an attribute allowed for the entry's objectclass. The aci may not even apply to the user running the operation. It can be any random attribute to trigger this bug.
Here's my test case:
[root@rhds 00776731]# ldapsearch -x -D "uid=jnansi,ou=people,dc=example,dc=com" -w redhat -h localhost "ou=restrictedusers" aci # extended LDIF # # LDAPv3 # base <dc=example,dc=com> (default) with scope subtree # filter: ou=restrictedusers # requesting: aci # # restrictedusers, example.com dn: ou=restrictedusers,dc=example,dc=com aci: (targetattr = "*") (version 3.0;acl "admin";allow (all)(userdn = "ldap:// /uid=jnansi,ou=People,dc=example,dc=com");) # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1
uid=jnansi can do modrdn operations:
[root@rhds 00776731]# ldapmodrdn -x -D "uid=jnansi,ou=people,dc=example,dc=com" -w redhat -h localhost "uid=aqwerty,ou=restrictedusers,dc=example,dc=com" "uid=terf" [root@rhds 00776731]#
I then change ACI to deny writes to the street attribute, the result is that the modrdn operation is denied. I have not illustrated this, but write operations to all attributes other then street will succeed:
[root@rhds 00776731]# ldapsearch -x -D "uid=jnansi,ou=people,dc=example,dc=com" -w redhat -h localhost "ou=restrictedusers" aci # extended LDIF # # LDAPv3 # base <dc=example,dc=com> (default) with scope subtree # filter: ou=restrictedusers # requesting: aci # # restrictedusers, example.com dn: ou=restrictedusers,dc=example,dc=com aci: (targetattr = "*") (version 3.0;acl "admin";allow (all)(userdn = "ldap:// /uid=jnansi,ou=People,dc=example,dc=com");) aci: (targetattr = "street") (version 3.0;acl "deny_street";deny (write)(userd n = "ldap:///anyone");) # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root@rhds 00776731]# ldapmodrdn -x -D "uid=jnansi,ou=people,dc=example,dc=com" -w redhat -h localhost "uid=terf,ou=restrictedusers,dc=example,dc=com" "uid=terf2" Rename Result: Insufficient access (50) [root@rhds 00776731]#
I add an explicit allow rule for the uid attribute, and the modrdn operation still does not succeed:
[root@rhds 00776731]# ldapsearch -x -D "uid=jnansi,ou=people,dc=example,dc=com" -w redhat -h localhost "ou=restrictedusers" aci# extended LDIF # # LDAPv3 # base <dc=example,dc=com> (default) with scope subtree # filter: ou=restrictedusers # requesting: aci # # restrictedusers, example.com dn: ou=restrictedusers,dc=example,dc=com aci: (targetattr = "*") (version 3.0;acl "admin";allow (all)(userdn = "ldap:// /uid=jnansi,ou=People,dc=example,dc=com");) aci: (targetattr = "street") (version 3.0;acl "deny_street";deny (write)(userd n = "ldap:///anyone");) aci: (targetattr = "uid") (version 3.0;acl "allow_uid";allow (all)(userdn = "l dap:///uid=jnansi,ou=People,dc=example,dc=com");) # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root@rhds 00776731]# ldapmodrdn -x -D "uid=jnansi,ou=people,dc=example,dc=com" -w redhat -h localhost "uid=terf,ou=restrictedusers,dc=example,dc=com" "uid=terf2" Rename Result: Insufficient access (50) [root@rhds 00776731]#
The argument here is that an aci for the street attribute must not influence the ability to change the RDN, especially since the deny rule should only apply to the street attribute and not to the uid attribute.
First: This is not a security risk, the server allows less access than expected, it may be incorrect, but no user can see more data than allowed.
Second: It is a question of interpretation if the behaviour is correct or not. There is no explicit rule for modrdn, the documentation has these two paragraphs:
In 1.3.3.3: Rights required for ldap operation
Modifying the RDN of an entry: Grant write permission on the entry. Grant write permission on the attribute type used in the new RDN. Grant write permission on the attribute type used in the old RDN, if you want to grant the right to delete the old RDN. Grant write permission on the value of attribute type used in the new RDN. This right is granted by default but could be restricted using the targattrfilters keyword.
And then in the 1.3.3.5 examples: To explicitly deny modrdn rights using ACIs, target the relevant entries but omit the targetattr keyword. For example, to prevent the cn=helpDeskGroup,ou=groups,dc=example,dc=com group from renaming any entries in the set specified by the pattern cn=*,ou=people,dc=example,dc=com, add the following ACI.
So it is the question what "write access" to an "entry", not an attribute exactly means. I think the current implementation expects write access to all attributes, and a deny rule for a single attribute can prevent this.
Third: In the specific test case the acis also prevent the adding of an attribute "street" by the bound user because of the deny to ldap:///anyone. But I have my doubt about this behaviour. If ldap:///anyone literally translates to "anybody" it is ok, but in my opinion it should translate to "anonymous" and not affect bound users
Ok, I reread the documentation and think I now understand the intended behaviour and what goes wrong.
There is no way to explicitely deny or allow modrdn operations, so it is handled via the "write" access to the entry. There is no way to eplicitely deny write access to an entry, only to targetattrs, so a deny(write) rule with no targetattrs is used to deny write to the entry. If there is a deny(write) for an attribute like street, the current implementation also denies access to the entry This could probably improved to make the code consitent with the doc and the original intention. BUT. The part of the code is quite complex and one needs to be careful not to break other scenarios. A rewrite and adding an explanation of what access to an entry means could be done, but I also woul recommend to redesign the customers acis to avoid the deny acis
In the corresponding bugzilla bug, it says that customer modified their acis and has a working environment, but thinks it should be fixed. So we could probably move the target of the fix to 1.3.2
Being the person who reported this case at red hat initially I agree that we use a proper workaround without deny acis and that this has low prio, fixing in 1.3.2 would be great.
attachment 0001-Ticket-47399-RHDS-denies-MODRDN-access-if-ACI-list-c.patch
commit to master
$ git merge ticket47339 Updating 6a0ed40..fe0491c Fast-forward ldap/servers/plugins/acl/acl.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) $ git push origin master Counting objects: 13, done. Delta compression using up to 4 threads. Compressing objects: 100% (7/7), done. Writing objects: 100% (7/7), 921 bytes, done. Total 7 (delta 5), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git 6a0ed40..fe0491c master -> master
git push origin 389-ds-base-1.3.1 Enter passphrase for key '/home/lkrispen/.ssh/id_rsa_fedora': Counting objects: 13, done. Delta compression using up to 4 threads. Compressing objects: 100% (7/7), done. Writing objects: 100% (7/7), 917 bytes, done. Total 7 (delta 5), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git aee7b9d..d9448c0 389-ds-base-1.3.1 -> 389-ds-base-1.3.1
Metadata Update from @lkrispen: - Issue assigned to lkrispen - Issue set to the milestone: 1.3.1.4
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/676
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.