Karl Fogel wrote:
> "C. Michael Pilato" <cmpilato_at_collab.net> writes:
>> Martin tells me that bzr-svn was banking on this ability to request
>> all revision logs from any location, because reparenting to the root
>> URL and fetching logs from there might not be permissible due to
>> access restrictions. So, if we assume a scenario where I'm allowed to
>> read /trunk but not /, presumably bzr-svn would use /trunk for the
>> session URL (which is allowed), but then ask for logs on /. Because
>> we only validate the returned logs, this would work fine -- we'd just
>> wind up return incomplete metadata for any revisions that contained
>> changed to paths outside of /trunk. As a general statement about the
>> usability of Subversion in auth-restricted scenarios, this kinda makes
>> sense. (We've seen other situations where, say, I can't do a move of
>> /trunk/foo to /trunk/bar because we try to anchor the commit editor at
>> /. Those kinds of things are easy to explain to a Subversion
>> developer, but users are left bewildered.)
>>
>> So, what to do? Do we explicitly allow absolute paths through all of
>> our RA interfaces? (Please don't make inconsistent policy here and
>> give per-method exceptions.) Do we stick with the published APIs and
>> send our best wishes and a vase of flowers to folks who were
>> previously misusing the APIs and have now been caught doing so?
>
> Why should access restrictions prevent someone from merely anchoring an
> RA session at a particular URL, and then running log requests based from
> that anchor? The access controls should, of course, limit what
> responses come back from the request, but I don't see why they should
> prevent what Martin assumes "might not be permissible".
Consider a situation in which mod_dav_svn (not mod_authz_svn) is configured
to disallow any read access to paths outside of /trunk. Before Subversion
even gets the chance to field a log REPORT request aimed at the root of the
repository, mod_dav_svn prevents the request from succeeding.
However, if the request was aimed at /trunk but its contents instructed
Subversion to grab all revision logs, then the "internal GET request" logic
we use in mod_dav_svn would still work correctly -- the nested GETs would
pass back through mod_dav_svn, which would permit stuff in and under /trunk
and disallow the rest -- and the resulting log stream would be as you'd
expect: all revisions present, but with metadata "cleaned up" per our
security rules.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-06-03 20:30:35 CEST