On Thu, 2003-04-17 at 09:03, Greg Stein wrote:
> Right. I see two basic issues:
>
> * you want ACLs to be independent of revisions. when you attach the "only
> group G can read this file" restriction when the repos is at rev 10, you
> also want it to apply to revs 1 through 9. Otherwise, people would just
> read the older file.
>
> Thus, you could say "ACLs should be path-based"
>
> * when you've attached an ACL to file F, you want to have the same
> protections on that file, even if it gets copied or moved.
>
> Thus, you could say "ACLs attach to specific objects"
>
> The two concerns are kind of mutually exclusive. I only say "kind of"
> because I believe there is a solution in there somewhere. I stopped applying
> brain-power to the problem when I recognize the big fork, and the resulting
> need to unify the two.
A potential rule to meet both of these requirements (sort of) occurred
to me the other day:
Only the ACL on the most recent revision of a resource actually
controls access.
This is a bit of a hack, but it kind of works like users expect. If the
ACL is stored as a versioned property, then you get ACL history, just
like everything else. You get to *see* what the permissions were, but
they don't apply unless you're looking at HEAD (i.e. you can see them,
but they don't apply to you looking at that revision, they're just
a record).
When a file is copied (branched), the ACL goes with it, just like
any other property.
When looking at historical versions of a file, there are two scenarios:
1) The file has no branches and only a single line of development.
The ACL of the most recent revision applies to all revisions.
Easy peasy.
2) The file branches in several places. This makes it hard to decide
if a user has access to revisions before the branch or not:
FileA(r100) -> FileA(r101) -> FileA(r102)
|
+----copy-----------> FileB(r103) -> FileB(r104)
For this scenario, permissions are as follows:
FileA(r100) u:daniel:rw
u:fred:r-
u:joe:--
FileA(r101) as in r100
FileA(r102) as in r100
FileB(r103) as in FileA(r100)
FileB(r104) u:daniel:rw
u:fred:--
u:joe:--
When the repository hits r104, suddenly, we are faced with a dilemma.
If we stick to the rule "the latest permissions are the ones that
count", then there is a problem with FileA(r101) and earlier. Which
permission applies, the deny or the allow? Can fred read or not
read FileA(r101). Can we identify the "primary" branch of a file,
and make *it's* permissions the default? Should permissions apply
in repository revision order (later branches override earlier ones,
or vis-versa?). Should we just be safe and deny?
I think it should be some kind of setting ("a deny overrides an allow
when a file branches", or "an allow overrides a deny when a file
branches"), both repository wide, *and* on a per-branch basis
(I'm not sure how it might be specified though, I haven't thought
*that* much about it).
daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 24 05:44:13 2003