[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] draft-zeilenga-ldap-assert-05 notes
Kurt D. Zeilenga writes:
>At 08:55 AM 2/26/2005, Hallvard B Furuseth wrote:
>>Kurt D. Zeilenga writes:
>>> (...)
>>> I think it would be reasonable to allow a user authorized to
>>> perform a modify to make that modify conditional.
>>
>> I hope not, if you mean conditional on any part of the entry. Then if I
>> have Modify access to attribute <foo> in an entry but attribute <bar> is
>> hidden from read/search/compare by access controls, I can subvert those
>> access controls by e.g. trying remove a non-existent value from <foo> or
>> modify it to contain the same value as before, conditional on a <bar>
>> filter. noSuchAttribute or success reveal that the filter matches the
>> "hidden" value of <bar>. assertionFailed reveals that it does not.
>
> Ah, but the client could have used its modify rights to do:
> changetype: modify
> delete: foo
> foo: bar
> -
> add: foo
> foo: bar
> -
>
> To see if that hidden <bar> exists. Or:
> control: no-op
> changetype: modify
> add: foo
> foo: bar
> -
Huh? None of these refer to attribute bar, only to an attribute value
of foo.
> My point here is that "right to modify" often implies a right
> to make assertions, at least certain kinds of assertions, as
> these assertions are necessary to perform the operation.
Yes. Still, only equality assertions, which fits Compare access
more than general search (filter) access.
>> Come to think of it, that can work even without Modify access. Getting
>> insufficientAccessRights instead of assertionFailed can reveal that the
>> assertion succeeded, unless the server implementor took care to check
>> all access controls before checking the assertion.
>
> The access control model may have "don't disclose on error"
> provisions.
True enough.
> (...)
--
Hallvard
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext