[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ACL with val.regex expression



>> 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