On Jan 12, 2005, at 9:13 AM, Mark Phippard wrote:
>>>
>>
>> That switch turns off all security checks in mod_dav_svn. Which means
>> that mod_authz_svn is rendered completely nonfunctional and useless.
>
> I do not think that is true at all.
Well, I wrote the feature, so I might know better. :-)
But you're right, I've oversimplified. See below.
> With this switch off you still get
> the fine-grained read/write control which is what I think most people
> want. What the switch seems to do is turn off the feature that was
> added
> to log where it does a get on each item in the log to check that you
> are
> authorized to see that the item was changed.
No, it doesn't just disable the new log-check. It disables *all* of
mod_dav_svn's ability to do internal read-checks.
What happens is:
1. an http request comes in.
2. mod_authz_svn decides if the user is allowed to execute the http
method.
3. if the request involves reading lots of paths, mod_dav_svn does
internal read-checks as it spools information back to the client.
For example, the checkout, update, blame, switch, diff and log commands
all send an http REPORT request. mod_authz_svn says, "hm, that's a
read request, and the username is allowed to read the root-path, so go
ahead." But then mod_dav_svn starts spooling whole trees (or lists of
paths) back to the client: any sub-path in the tree could be
unreadable. So mod_dav_svn does an "internal" GET request on each
sub-path.... which then implicitly re-invokes mod_authz_svn for
approval of each sub-path.
So, for example, you may have set up an SVNAuthzAccessFile to make
/trunk world-readable, but then decided that certain users aren't
allowed to read /trunk/private/. When a restricted user does a
checkout of /trunk, normally /trunk/private/ would be skipped
altogether. But with 'SVNPathAuthz off', mod_dav_svn stops doing GET
subrequests on sub-paths, so the user gets everything.
In theory, mod_authz_svn's ability to enforce per-path write access
shouldn't be affected. I've not tested it in practice.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jan 12 16:44:17 2005