Re: Security considerations, was Re: Area Director feedback on draft-reschke-webdav-search-15 re supported query complexity

Julian, your recent posting of draft version 17 reminded me about this thread.
Sorry for my late reply, this week have been too complicated for me.

In order to not delay the Last Call, I think it can be closed with no action
(other than changes already applied in version 16).


On Wed, 02 Jul 2008 21:24:16 +0200,  Julian Reschke wrote:

>
> Javier Godoy wrote:
>> ...
>>>    o  Query constraints on content (as with DAV:contains, defined in
>>>       Section 5.16) for which the client does not have read access need
>>>       to be evaluated as if a GET would return a 4xx status code.
>>
>> And is the result of this evaluation FALSE? or is it UNKNOWN?
>> I would expect the latter because expressions on properties evaluate as
>> UNKNOWN when the property is not defined, but Section 5.16 states that [[
>>  The DAV:contains operator (...) evaluates to TRUE if the content of the
>> resource satisfies the search. Otherwise, it evaluates to FALSE.
>> ]]
>
> Would that be a problem?

I think it is a detail, not a problem.

IMHO it would be more correct to define UNKNOWN as the result of
non-evaluable operands about the content, instead of FALSE, but I also think it
has no practical implication.

When "not contains" is applied to a resource for which the client has no read
access,
it would evaluate as TRUE (instead of UNKNOWN) .

Then a query criteria specifying "other_condition AND not contains" would be
evaluated as:
 other_condition AND not FALSE = other_condition
instead of
 other_condition AND not UNKNOWN
which may be FALSE (if the other condition is false) or UNKNWON (if
other_condition is UNKNOWN or TRUE)

But criteria like "other_condition AND not contains" seems not to be very
useful (e.g., Content-Length <=1024 AND not contains "foobar").

(Just out of curiosity I asked Google for "not contains foobar" and it found 2
results: http://tinyurl.com/6ajobc ;-)


> I personally do not have a preference, and the DASL implementation I did a
> few years back did not support DAV:contains anyway.

As explained above, I do not see a reason for evaluating as FALSE, and I think
an implementation
doing so would be faulty, but that fault would be (almost) imperceptible.

The truth value UNKNOWN is explained in detail in Appendix A, and that
explanation is consistent with the case under discussion.


>>> I'm not too enthusiastic to add more RFC3744 related language; after
>>> all, some of the SEARCH implementations do not support RFC3744 anyway,
>>
>> IMHO, if the DAV:supported-query-grammar-set property is REQUIRED when
>> both RFC 3744 and SEARCH are supported, then the interaction between both
>> extensions should have been regarded as important at some point in the
>> developement of DASL / SEARCH.
>
> Honestly, I don't think so.
>
> The text you're referring to was put in because the original feature
> discovery in DASL was broken (in that the DASL header uses URIs, while the
> request body uses expanded names), so this was put as an afterthought for
> "modern" servers.

I'm not following you. Do you mean it is broken because "[although] the URIs
can be used to identify each supported search grammar, there is not
necessarily a direct relationship between the URI and the XML element name
that can be used in XML based SEARCH requests"?

Identifying a grammar by URI, when it could be identified by namespace and
element name is an unnecessary complication, but something we could live
with: if a client doesn't know the URI, likely it will not know about the
identified grammar, then providing the element name does not help (it cannot
write a query using that grammar);
conversely, if it knows the grammar it will know the URI.

Other thing I don't understand is why DAV:supported-query-grammar-set is
REQUIRED when RFC 3744 is supported. If it comes to fix a flaw with the DASL
header, it is useful despite of whether RFC 3744 is supported or not. I
guess it may be because "old" servers, implementing only the DASL header,
didn't know about 3744, then the requirement only applies to newer servers
(?)


>> SEARCH (at least, basicsearch) already defines it own
>> mechanism for advertising privileges in QSD responses. A property for
>> which the clien has no privileges is neither DAV:selectable,
>> DAV:searchable nor DAV:sortable... and that should be enough.
>
> Which of course raises the question whether the result of QSD should
> reflect privileges; this may be very hard to implement.

Not only hard to implement, but probably a bad idea...  Even though my first
though was that they should (not at a requirement level, but as a hint about a
restriction which is not described anywhere else), analyzing it carefully, now I
realize that QSD property descriptions and privileges are very different: QSD
describes the properties of all the resources searchable through the arbiter, or
the properties of all the resources within the specified scopes, while
privileges are defined on a per-resource basis.

The client may have read access for some property in a sub-scope of the scope
being described by QSD, then the server should look up ACLs for every resource
within scope before considering some property as "not searchable" (it will be
easy if the client is never allowed to read that property, otherwise I think it
may be too much computation for nothing).

Other caveat: "If a property does not have such a description, or is not
described at all, then the server MAY still  allow the property to be used in
the corresponding section." (section 5.9.12). The interpretation of omitted
descriptions is up to the client (which I think will suppose the query is
allowed, or will not care about the QSD at all) .


>> However, a brief statement about RFC 3744 in Section 7 should not harm
>> anyone (just a suggestion, it is up to you, +1 anyway)
> Any proposals?

Lack of RFC 3744 privileges is one possible interpretation of the actual
wording: "the client does not have read access".

If one want to be explicit, one could say "Read access may be determined by
Access Control Protocol [RFC 3744], or other server-specific mechanisms." But
i'm afraid it is very very obvious.


Best Regards

Javier

Received on Saturday, 12 July 2008 19:23:48 UTC