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?
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? At the
moment, I suspect it will fail: mod_authz_svn will spring to life on
the GET request, completely ignore the querystring, default to HEAD
and decide that the path is unreadable. This happens before
mod_dav_svn ever even gets to parse the thing. If we want to fix
this, I suspect that we're going to have to make mod_authz_svn
"borrow" the same history-tracing query-parsing logic that I just put
into mod_dav_svn. This isn't so weird, since mod_auth_svn already
calls mod_dav_svn's main dav_svn_split_uri() parser to decode
(rev,path) in deltaV URIs. Is this the Right Thing to do?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-07 05:37:48 CET