The issue here is that the log-fetching is a single HTTP request on
the parent directory (REPORT). mod_auth_svn says, "ah, anybody can
read this directory, so I'm not going to ask for authentication at
all." Then when the log-traversal hits a change that affects the
restricted area, there's no opportunity to authenticate. The lack of
authentication is 'permanent' for the whole request, and thus the
anonymous reader is denied access to the one area.
I can't think of a solution here; there's no way apache can halt in
the middle of streaming a long response and demand authentication.
On Aug 6, 2005, at 2:11 AM, Michael W Thelen wrote:
> Subversion server 1.2.1 (Apache with mod_authz_svn) sometimes
> restricts
> access to log information even when a user has read/write access to
> the
> area being restricted. This only happens if the user requests log
> information for a directory above the restricted directory.
> Requesting
> log information on the restricted directory itself works fine. Here's
> what I mean:
>
> My access file looks like this:
>
> [projects:/]
> * = r
> mike = rw
>
> [projects:/foo/trunk/restricted]
> * =
> mike = rw
>
> The user mike can commit to /foo/trunk/restricted. Running svn log
> directly on the restricted directory works as you would expect:
>
> $ svn log http://svn.example.com/projects/foo/trunk/restricted --
> limit 1
> ----------------------------------------------------------------------
> --
> r689 | mike | 2005-08-06 00:43:55 -0600 (Sat, 06 Aug 2005) | 1 line
> Changed paths:
> M /foo/trunk/restricted/thingy.pl
>
> Add meaningless change.
> ----------------------------------------------------------------------
> --
>
> Running svn log on a directory above the restricted one produces this:
>
> $ svn log http://svn.example.com/projects/foo/trunk --limit 1
> ----------------------------------------------------------------------
> --
> r689 | (no author) | (no date) | 1 line
>
>
> ----------------------------------------------------------------------
> --
>
> It looks like maybe the fix for the CAN-2004-0749 security issue
> (r11102) may have been a little too restrictive? Unfortunately I
> can't
> test the trunk code right now to see if it still has this behavior.
>
> --
> Michael W Thelen
> It is a mistake to think you can solve any major problems just with
> potatoes. -- Douglas Adams
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Aug 6 14:55:24 2005