On 4/7/06, Garrett Rooney <rooneg@electricjellyfish.net> wrote:
> Well, we don't have to execute the hook for each path, we could send
> them in on stdin or something like that.
We have to pay attention to stdin deadlock - but, yah, that should work.
> Or perhaps a subset of the
> information could be useful. I mean for checkouts or exports the
> important thing is the source path, you don't really have anything
> else. Do we really NEED every path passed to the reporter to make a
> useful decision?
I think so, depending upon whether we to force the admin to manually
put in every parent path to block just one dir or require the hook
script to have logic to block all ancestors of those in the excluded
list.
Consider the following case where an admin wants to block a checkout
on just /project/branches/ and /project/tags - the admin wants to
force users to do a checkout of the dir underneath that (i.e. just a
single branch or a tag). However, the admin also needs to block / and
/project/ because if a malicious user specified /project, they'd route
around the blockage.
Without checking the child paths (sucks for SVN as this degrades to
authz and hooks suck at this) or their parents (sucks for the hook
script as it's generally getting more complicated than just a simple
script), you can accidentally open a hole the admin thought they
closed.
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... --
justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 8 06:50:59 2006