On 10/18/2013 02:53 PM, Mark Dieterich wrote:
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.
Just for the records, I set
access to attrs=description val.regex="^/bin/[^f][^s][^h]" by users write by * read
access to * by * read
(I didn't feel like populating the database with homeDirectory and so), and it worked: users were able to add/delete "/bin/bash", but not "/bin/fsh".
Glad you found a workaround, though.
p.
Thanks,
Mark