Ben Collins-Sussman wrote:
> mod_dav_svn implements a fancy authz_read() routine (an instance of
> the famous svn_repos_authz_func_t), and uses it when responding to all
> sorts of fancy REPORT requests. It tests readability by issuing a
> private GET subrequest, which then triggers mod_authz_svn, which then
> uses mod_dav_svn's parsing logic on the (possibly opaque, deltaV-ish)
> URI to figure out the (rev,path) pair being read. So far so good.
> mod_authz_svn therefore covers the case of browsers doing 'GET
> /repos/path' or even 'GET /repos/!svn/bc/23/path'.
>
> But for the new syntax I just submitted ('GET
> /repos/path?p=PEGREV&r=WORKINGREV'), I think there are two security
> issues that possibly need fixing:
>
> 1. When parsing the querystring, mod_dav_svn calls
> svn_repos_trace_node_locations() without the authz_read callback. We
> should probably pass mod_dav_svn's authz checker here, to make sure we
> don't trace history back into an unreadable zone, right?
Yes.
> 2. If a path is unreadable in HEAD but readable at an earlier peg
> revision, then should 'GET /repos/path&p=PEG' succeed or fail?
It should fail as an extension of the rule applied in (1) above.
/repos/path_at_PEG is located, by definition, at /repos/path in the PEG
revision. So the very first point along this thing's history is already
known to be unreadable, right? I would suspect that even if mod_authz_svn
didn't fail on the incoming request, svn_repos_trace_node_locations() would
quickly realize that it *begins* its trace in an unreadable zone. The
result is the same -- no visibility for the object.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-11-07 15:02:44 CET