On 4/7/06, Justin Erenkrantz <justin@erenkrantz.com> wrote:
> My strawman is that we treat this as an authz mode - think Unix
> non-inherited execute perms on dirs. For simplicity sake, it probably
> should actually be the *opposite* of x in Unix (if it's set, don't
> allow this dir to be checked out), but so you can see where I'm
> going...like so:
>
> [/]
> * = rx
> admins = rw
>
> [/project]
> * = x
> committers = rwx
>
> [/project/branches]
> * = x
>
> [/*/tags]
> * = x
>
> I forget if mod_authz_svn will expand regexes in the config file...(it
> could, I guess)
>
> The authz checks we already do would do the right thing if we extended
> it to represent these semantics and checked for this when driving the
> update editor - have it send 'absent-directory' to the client...
Ok, so this seems to be a reasonable approach, so I decided to
investigate a bit and see how it would be implemented.
Actually adding a concept of 'x' permissions to the authz format is
simple, you can just reserve some more bits in
svn_repos_authz_access_t for the purpose.
The more complicated issue is figuring out where to make the call to
svn_repos_authz_check_access.
As usual, with svnserve it's not all that big a deal, we can just
stick them inside the update and replay functions, since authz is
handled inline for that code anyway, and enough information is
available to determine that something is a checkout/export at that
point.
Adding support to mod_authz_svn is more tricky. We don't actually
know that we're doing a replay or checkout at the point where we do
most of the authz checking, so we'll have to jump through hoops,
attaching an input filter that looks at the REPORT body and figures
out if it's a checkout or report. Not impossible (I mean I already
wrote that code in mod_limit_svn), but not simple either.
So before I run down this path further, do people think it's worth
pursuing? In the meantime I want to investigate the hook script idea,
and see if the performance implications are actually noticable.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 11 23:29:18 2006