On Tue, Feb 10, 2009 at 08:41:53AM -0500, Mark Phippard wrote:
> On Tue, Feb 10, 2009 at 8:01 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> > On Tue, Feb 10, 2009 at 11:20:41AM +0000, Stefan Sperling wrote:
> >> On Tue, Feb 10, 2009 at 11:13:28AM +0000, Stefan Sperling wrote:
> >> > On Mon, Feb 09, 2009 at 10:34:25PM -0500, Eli Barzilay wrote:
> >> > > [Apologies if this is a known issue, I've tried too look around for
> >> > > this for some time now and didn't see anything.]
> >> > >
> >> > > We have a private user repository, protected by an authz configuration
> >> > > file. Some people have encountered a problem where things die with an
> >> > > obscure
> >> > >
> >> > > svn: Server sent unexpected return value (403 Forbidden) in response
> >> > > to OPTIONS request for 'http://svn.plt-scheme.org/usr'
> >> > >
> >> > > Now, as far as I can tell, this is correct for our setup, since /usr
> >> > > is the repository root which is not supposed to be readable, and
> >> > > /usr/foo would be the directory for `foo'. We've managed to find a
> >> > > way to reproduce this which looks like the following:
> >> > >
> >> > > svn co http://svn.plt-scheme.org/usr/foo A
> >> > > svn co http://svn.plt-scheme.org/usr/foo B
> >> > > cd A
> >> > > touch blah1
> >> > > svn add blah1
> >> > > svn ci -m ''
> >> > > svn mv blah1 blah2
> >> > > svn ci -m ''
> >> > > cd ../B
> >> > > svn up
> >> > > <<403-error>>
> >> > >
> >> > > After some tweaking of my ~/.subversion/servers, I've managed to get
> >> > > some verbose output -- and it looks like the problem happens when it
> >> > > tries to get the new "blah2" file -- the output has
> >> > >
> >> > > <D:checked-in><D:href>/usr/!svn/ver/20822/foo/blah2</D:href></D:checked-in>
> >> > >
> >> > > and then it immediately proceeds to perform the offending OPTIONS:
> >> > >
> >> > > HTTP session to http://svn.plt-scheme.org:80 begins.
> >> > > HTTP session to http://svn.plt-scheme.org:80 begins.
> >> > > Doing DNS lookup on svn.plt-scheme.org...
> >> > > Running pre_send hooks
> >> > > compress: Initialization.
> >> > > Sending request headers:
> >> > > OPTIONS /usr HTTP/1.1
> >> > > Host: svn.plt-scheme.org
> >> > > User-Agent: SVN/1.5.5 (r34862) neon/0.25.5
> >> > > ...
> >> > > [status-line] < HTTP/1.1 401 Authorization Required
> >> >
> >> > Could this be normal behaviour because the client is asking the server
> >> > about capabilities?
> >> >
> >> > In trunk, looking at libsvn_ra_neon:svn_ra_neon__exchange_capabilities(),
> >> > it passes ras->url->data to svn_ra_neon__request_create(), which has this
> >> > code at the top:
> >> >
> >> > /* We never want to send Neon an absolute URL, since that can cause
> >> > problems with some servers (for example, those that may be accessed
> >> > using different server names from different locations, or those that
> >> > want to rewrite the incoming URL). If the URL passed in is absolute,
> >> > convert it to a path-absolute relative URL. */
> >> > const char *path = path_from_url(url);
> >> >
> >> > Could this be where "svn.plt-scheme.org/usr" is converted to just "/usr",
> >> > causing incompatibility with the configured authz scheme?
> >>
> >> That could have been worded better: I didn't mean to say that translating the
> >> URL this way causes the problem. The cause of the problem would of
> >> course be that we're asking about capabilities at the repository root
> >> in the first place.
> >
> > See also http://subversion.tigris.org/issues/show_bug.cgi?id=3242
>
> I think that issue is specific to the copy command though. In 1.5 it
> was changed so that it "anchors" the session at the common parent of
> the resources. IMO, this has caused an authz regression and we should
> fix it. However, I am not sure it applies here since copy is not
> being used.
Thanks for clarifying.
> In the case of the OPTIONS request, does authz even look at that? If
> so, why wouldn't it just approve the request if you successfully
> authenticate? I cannot see why you would need read access to root to
> answer this request.
Don't assume that I know how capability negotiation or authz work :)
I was just suggesting this as a possible cause for the problem,
but unless further investigation shows that my suspicion is true,
it may well be something else.
Stefan
Received on 2009-02-10 14:56:15 CET