On May 30, 2009, at 4:46 PM, Rupert Wood wrote:
> Hyrum K. Wright wrote:
>> which results in
>> svn: Server sent unexpected return value (403 Forbidden) in
>> response to PROPFIND request for '/svn'
> Here's the hack we use locally to mitigate this: allow OPTIONS and
> PROPFIND at the repository root for all authenticated users. It
> broadly seems to do the trick and for most operations just OPTIONS
> will do.
I haven't reviewed the patch, but I think the idea of having looser
restrictions on when we return OPTIONS is valid. IIRC, the response
to OPTIONS is per-repository, meaning that it won't change depending
on which path the user is accessing. It sounds like the cause of
#3242 is an unfortunate interaction between common parent reparenting,
and the OPTIONS stuff introduced in 1.5. Perhaps this is a creative
way to solve it?
(The only information I could see leaking is the fact that the path
exists. But the path is a parent of something the user already has
access to, so the user should already know the path exists, so it's
not really leakage at all.)
In other news, while looking through the lock code earlier today, I
noticed we open an ra session to the common parent of all the lock
targets, so it would probably have the same problem as #3242. We
probably haven't heard much about it because people probably don't try
to lock paths in different parts of a repository using the same
command very often.
> I meant to work out if this was sufficient and not too dangerous
> sometime before passing the patch on - I haven't done this, and
> sounds like it this isn't even remotely correct, so I'm not really
> proposing this as a patch. But here goes anyway in case it's useful.
> Hack work-around for issue 3242.
> * subversion/mod_authz_svn/mod_authz_svn.c:
> Permit OPTIONS and PROPFIND at repository root for all authenticated
Received on 2009-06-02 19:22:22 CEST