So Lundblad and myself, along with other random passers-by on
#svn-dev, have been talking about the replay authz stuff that we've
been trying to get in before 1.4, and we figured it should be
summarized and sent to the list.
Basically, the desired change to authz would be something like this.
We add a new permission that controls the ability to execute
operations that recurse through an entire subtree, which includes
things like update, checkout, diff, merge, status -u, and replay.
This is possible to implement, although it is tricky in some spots.
The problem with this is how is it configured in the authz config
file? Well, first off there's the fact that just naively adding this
new option changes the semantics of current authz files. So something
like this:
[/]
* = rw
Used to mean "everybody has full access to the tree", but now means
"everybody has full read write access, but can't actually checkout or
update anything because they never got this new access". So we can
work around that by requiring the user to explicitly say this new
permission exists or something like that, but ick.
Alternatively, we could invert the sense of the new permission, but
then you're stuck with one permission type that's totally different
from the others, which is confusing.
Next, there's the issue that people now really need to carry around
this new permission all over the place, whenever they add a more
specific rule. For example, if I want to keep people from writing to
a specific subdir, I used to be able to do this:
[/]
* = rw
[/foo]
* = r
Now I need something like:
[/]
* = rwc
[/foo]
* = rc
(assume c is our new 'reCursive' permission)
This kind of sucks, but our authz system doesn't have any concept of
inherited permissions, or negative permissions, or anything like that,
so it's the best we can do without big changes.
One potential solution here is to have c be implied by some other
stuff, for example if you have w access someplace you also get c for
free, but then you lack the ability to give someone the ability to
modify a directory without checking it out, which is bad because you
wouldn't be able to allow someone write access on say 'branches'
without also letting them check out branches.
Lundblad wants to allow things like +w or -w, inheriting the rest of
the perms from parent directories, but like I said, that's a bit of
work because we currently don't have anything like that, and it has
potential performance implications due to requiring us to look further
up the directory tree before we can be sure about a given answer.
Also note that all of this stuff really needs to play nicely with
wildcards, otherwise you have to set these permissions in a zillion
places, which is a non-starter. Wildcards are not especially trivial.
I've got a sort of working patch, but it's not done, and it will
require substantial review from a user experience perspective, to make
sure it does what we think users will want.
At this point in the conversation, we started to wonder if it was even
possible to implement a good authz based solution in a reasonable
amount of time, especially taking into account that you really don't
want to drop a massive authz change in right before a release. So we
started to consider alternative plans.
The main alternative is read hooks of some sort, but let's face it,
those are just as complex as this authz stuff. Alternatively, we
could just provide a work around for the problem, allowing users to
turn off replay if they're so inclined, so at least we're not any
worse off than we were in 1.3.x.
Anyway, at this point I'm not sure what we should be doing.
Personally, I think I can implement solutions to the replay problem
for sites I'm responsible for, they won't be integrated with our
existing authz stuff, and they won't be especially nice, but they'll
work, and they'll allow us to move forward wihtout introducing massive
changes right before this release. Alternatively, we can implement a
stopgap solution like defaulting replay to off, or allowing users to
turn it off if they're so inclined, but that means we decide to not
solve the update problem right now. Finally we could back off and try
to find a more correct solution to this problem, but we need to
recognize that it's nontrivial, and requires some serious effort.
If anyone else has some feedback on this, I'd love to hear it. I feel
like this is an important issue, and I'm really not sure what our
short or long term answer to it should be at this point.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 4 00:28:58 2006