[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: SVN-DEV HELP NEEDED: What to do about the ra-get-log interface

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Tue, 03 Jun 2008 14:30:18 -0400

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.