>> I'm at a loss as to why adding the "val.exact=/bin/bash" requirement >> changes the acl trace from doing: >> >> 525edc6e <= check a_dn_pat: cn=replica,dc=cs,dc=brown,dc=edu >> 525edc6e <= check a_dn_pat: self >> >> to >> >> 525ed68a <= check a_dn_pat: cn=replica,dc=cs,dc=brown,dc=edu >> 525ed68a <= check a_dn_pat: >> uid=.*,ou=people,dc=cs,dc=brown,dc=edu,cn=gssapi,cn=auth >> >> with the val.exact statement, it doesn't even seem to evaluate the >> "self" permissions. Am I missing something fundamental here? > > When modifying a value with a "replace" modify, first access is checked > without values, to make sure one has the right to delete whatever value > is present. With the ACL you configured there is no such privilege. You > need to split your operation in two: first delete the specific value you > want to delete, then add a new value. Both need to comply with the > pattern specified in your ACL.
If I read this correctly, what you are saying is any val.<type>=<test> is completely ignored during the first check of a "replace" modify? This seams like slapd is changing the semantics of my intended ACL. If I truly don't want a user to be able to modify/delete a record unless it matches a given set of values, then what's stopping them from working around any ACL restriction I put in place with the explicit delete & add procedure you outlined? As an aside, I went ahead and tested the explicit delete and add procedure, it failed as well. I was using slapacl for my tests and I'm not sure how it knows whether the intended procedure is a delete, add, or modify. All I was telling it to test for was whether it could write a particular attribute. Thanks, Mark
