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

----- Original Message ----- 
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Javier Godoy" <rjgodoy@fich.unl.edu.ar>
Cc: "Jim Davis" <jrd3@alum.mit.edu>; <www-webdav-dasl@w3.org>
Sent: Wednesday, July 02, 2008 12:29 PM
Subject: Re: Security considerations, was Re: Area Director feedback on 
draft-reschke-webdav-search-15 re supported query complexity


>
> Javier Godoy wrote:
>> ...
>> [[
>>   A query must not allow one to retrieve information about values or
>>   existence of properties that one could not obtain via PROPFIND. (e.g.
>>   by use in DAV:orderby, or in expressions on properties.)
>> ]]
>>
> In the meantime, this says:
>
>    A query MUST NOT allow clients to retrieve information that wouldn't
>    have been available through the GET or PROPFIND methods in the first
>    place.  In particular:
>
>    o  Query constraints on WebDAV properties for which the client does
>       not have read access need to be evaluated as if the property did
>       not exist (see Section 5.5.3).

+1


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

There is either an omission in 5.16, or a not-so-obvious choice because of 
compatibility or other issues (?) which may be explictly stated.

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


> so it seems to be a better approach to describe this in terms of whether 
> the client is able to GET the content/PROPFIND a property (thus talk about 
> status codes, not RFC3744 privileges).

I agree about not being too verbose about RFC 3744 details, but because of a 
different reason: the *only* standard privilege (let alone the DAV:acl 
property) from RFC 3744 that applies to SEARCH is DAV:read, which affects 
both GET and PROPFIND. Generally, properties are controlled by DAV:read or 
by a non-standard privilege aggregated under DAV:read. Therefore, the RFC 
3744 language is not enough for defining the behavior of the SEARCH method 
and GET/PROPFIND fits better.

Furthermore, 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.

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


Best Regards

Javier

Received on Wednesday, 2 July 2008 18:19:33 UTC