You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Karl Fogel <kf...@red-bean.com> on 2008/06/03 18:12:06 UTC
Re: SVN-DEV HELP NEEDED: What to do about the ra-get-log interface
"C. Michael Pilato" <cm...@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".
If there is a bug here, perhaps it's in the way the server enforces
access restrictions?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SVN-DEV HELP NEEDED: What to do about the ra-get-log interface
Posted by Karl Fogel <kf...@red-bean.com>.
Stefan Sperling <st...@elego.de> writes:
> On Wed, Jun 04, 2008 at 08:56:31AM -0400, Mark Phippard wrote:
>> On Wed, Jun 4, 2008 at 8:48 AM, C. Michael Pilato <cm...@collab.net> wrote:
>> > We do not anticipate making a change here, and I'd love to see RC9 rolled
>> > ASAP (though there appears to be an obvious-fix item still in STATUS).
>>
>> RC9 was rolled last night. When I looked at STATUS there were no
>
> I added a totally obvious fix for the INSTALL file today (mention
> neon-0.28 support).
For what it's worth:
When the time comes to do the real release, I'd think it would be fine
for Hyrum to incorporate whatever INSTALL or other doc changes he wants.
We can diff the final release against RC9 and see that there are no
changes in sensitive areas, after all (and I would be doing so anyway).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SVN-DEV HELP NEEDED: What to do about the ra-get-log interface
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Jun 04, 2008 at 08:56:31AM -0400, Mark Phippard wrote:
> On Wed, Jun 4, 2008 at 8:48 AM, C. Michael Pilato <cm...@collab.net> wrote:
> > We do not anticipate making a change here, and I'd love to see RC9 rolled
> > ASAP (though there appears to be an obvious-fix item still in STATUS).
>
> RC9 was rolled last night. When I looked at STATUS there were no
I added a totally obvious fix for the INSTALL file today (mention
neon-0.28 support).
Stefan
Re: SVN-DEV HELP NEEDED: What to do about the ra-get-log interface
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Jun 4, 2008 at 8:48 AM, C. Michael Pilato <cm...@collab.net> wrote:
> We do not anticipate making a change here, and I'd love to see RC9 rolled
> ASAP (though there appears to be an obvious-fix item still in STATUS).
RC9 was rolled last night. When I looked at STATUS there were no
remaining items in it.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SVN-DEV HELP NEEDED: What to do about the ra-get-log interface
Posted by "C. Michael Pilato" <cm...@collab.net>.
Mark Phippard wrote:
> On Tue, Jun 3, 2008 at 3:45 PM, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
>> On Tue, Jun 3, 2008 at 12:16 PM, C. Michael Pilato <cm...@collab.net> wrote:
>>> I'm not saying its a sane configuration, of course. But prior to
>>> mod_authz_svn being created, it was through Apache configury like this that
>>> we instructed folks to do their access control.
>> Not permitting access into the special URI space is kinda pointless -
>> hence, mod_authz_svn. I don't think we should bend over backwards to
>> support broken configs. -- justin
>
> Is it "safe" for Hyrum to roll RC9 tonight with the fix for
> depth=empty and that changelist fix? Or do we anticipate making a
> change here? It sounds like we are not making any changes, but I
> wanted to be sure.
We do not anticipate making a change here, and I'd love to see RC9 rolled
ASAP (though there appears to be an obvious-fix item still in STATUS).
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: SVN-DEV HELP NEEDED: What to do about the ra-get-log interface
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Jun 3, 2008 at 3:45 PM, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> On Tue, Jun 3, 2008 at 12:16 PM, C. Michael Pilato <cm...@collab.net> wrote:
>> I'm not saying its a sane configuration, of course. But prior to
>> mod_authz_svn being created, it was through Apache configury like this that
>> we instructed folks to do their access control.
>
> Not permitting access into the special URI space is kinda pointless -
> hence, mod_authz_svn. I don't think we should bend over backwards to
> support broken configs. -- justin
Is it "safe" for Hyrum to roll RC9 tonight with the fix for
depth=empty and that changelist fix? Or do we anticipate making a
change here? It sounds like we are not making any changes, but I
wanted to be sure.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SVN-DEV HELP NEEDED: What to do about the ra-get-log interface
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Tue, Jun 3, 2008 at 12:16 PM, C. Michael Pilato <cm...@collab.net> wrote:
> I'm not saying its a sane configuration, of course. But prior to
> mod_authz_svn being created, it was through Apache configury like this that
> we instructed folks to do their access control.
Not permitting access into the special URI space is kinda pointless -
hence, mod_authz_svn. I don't think we should bend over backwards to
support broken configs. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SVN-DEV HELP NEEDED: What to do about the ra-get-log interface
Posted by "C. Michael Pilato" <cm...@collab.net>.
Karl Fogel wrote:
> "C. Michael Pilato" <cm...@collab.net> writes:
>>> 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.
>
> That's what I'm questioning. Why does mod_dav_svn behave like this?
> Because it's easier to implement?
Does it have a choice?
I think we're thinking of different deployment scenarios. I'm talking about
something like:
<Location /repo>
DAV svn
SVNPath /var/svn/repo
### bits that disallow access here
</Location>
<Location /repo/trunk
### bits that allow access to trunk here
</Location>
IIUC, a request to /repo (or to /repo/something-not-trunk) wouldn't even get
to mod_dav_svn for processing because it fails the higher-level Apache authz
requirements.
I'm not saying its a sane configuration, of course. But prior to
mod_authz_svn being created, it was through Apache configury like this that
we instructed folks to do their access control.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: SVN-DEV HELP NEEDED: What to do about the ra-get-log interface
Posted by Karl Fogel <kf...@red-bean.com>.
"C. Michael Pilato" <cm...@collab.net> writes:
>> 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.
That's what I'm questioning. Why does mod_dav_svn behave like this?
Because it's easier to implement?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SVN-DEV HELP NEEDED: What to do about the ra-get-log interface
Posted by "C. Michael Pilato" <cm...@collab.net>.
Karl Fogel wrote:
> "C. Michael Pilato" <cm...@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 <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand