On Feb 10, Stefan Sperling wrote:
>
> 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?
>
> 1.5 has similar code in libsvn_ra_neon/session.c:exchange_capabilities().
>
> Looks like 1.4 did not do this capabilities exchange.
Yes, I forgot to add that we've been having these problems only after
the 1.5 upgrade.
> Basically, if this explains the problem, then denying access to the
> repository root via authz cannot be done in 1.5 because of the way
> the capabilities exchange has been implemented.
So it looks like this is the case -- not that it's impossible, but
that sometimes it will get stuck in a way that cannot be recovered
other than removing the stuck WC.
On Feb 10, Stefan Sperling wrote:
>
> See also http://subversion.tigris.org/issues/show_bug.cgi?id=3242
Yes, I've seen that bug before (and for some reason I assumed that it
was closed).
On Feb 10, Mark Phippard wrote:
> On Tue, Feb 10, 2009 at 8:01 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> >
> > 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.
This does sound very similar to our problem. We get it as a result of
`svn mv', and it happens right after it sees a copyfrom property.
(The only difference is that we have a problem with OPTIONS and the
bug shows a problem with PROPFIND.)
It looks like I should file another bug report?
> 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.
(FWIW, after fiddling with the apache configuration for a while I
eventually just removed all permissions from it, and do everything
through the authz configuration. So now the problem that we see is
caused strictly by authz forbidding access -- and IIUC, it's doing the
right thing.)
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1142338
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-12 03:53:29 CET