-----BEGIN PGP SIGNED MESSAGE-----
David Anderson wrote:
> Ben Collins-Sussman wrote:
>>> A check in the code, and a short discussion with David Anderson on irc learned that:
>>> - svnserve requires read access to the repository root for commits.
>>> - this behaviour is by design.
>>> - mod_authz_svn doesn't have this behaviour, making both implementations of the
>>> same authz model incompatible
>> Before jumping into a patch, I'd like to understand *why* there are
>> these two different behaviors in our servers.
>> David Anderson: why is the new behavior intentional?
> It is intentional because, lacking any execution cap in authz, it made sense to
> me to require read access for traversing the repository prior to writing to it.
> How can someone write to a path which he couldn't actually read? Now of
> course, in the light of this bug, I realize that this point of view is flawed.
> I had asked at the time of modifying the commit editor about this ("Should the
> commit editor require read access to the root?"), and was told that yes, the
> commit editor should enforce this. I won't play pass the buck, as this problem
> is likely ascribable to my relatively short experience with both authz and svn
> editors when I wrote that change in.
> I think that the difference here is that I took 'r' to mean 'rx', whereas
> mod_authz_svn takes 'x' for granted and means 'r' litterally. In the former
> case, svnserve's behaviour is valid; in the latter case, mod_authz_svn's
> behaviour is valid.
> So, my take on all this is that svnserve's implementation is indeed faulty, as
> it was supposed to copy mod_authz_svn's implementation. The solution is to
> either correct svnserve (I believe the fix is a two-liner - remove read access
> check on opening directories in the commit editor), or introduce an 'x' bit that
> explicitely identifies the right to traverse directories.
Let's do the minimum fix to make svnserve behave the same as mod_*_svn
for now, and get that into 1.3.1.
Then, we can consider the need for traverse checking more carefully -
special-casing the root seems wrong to me, as surely any situation which
could apply there could also apply at any deeper place in the hierarchy.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
-----END PGP SIGNATURE-----
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Jan 24 12:43:10 2006