Response to: http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=35763
(Daniel Patterson)
> 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?
Actually there is no dilemma in the above example if ACL is unversioned
property on the file. User fred can sync to r104 but r100-r103 is out
of his access. Later on, administrator of the repository decides
that fred should not access r100 at all. For that he
(administrator)changes property on FileA(r100) from u:fred:r- to u:fred:--.
That is all. From that moment and until administrator allows fred can not
read from r100. Of course, there should be a svn flag allowing to change
ACL property recursively on all subsequent branches of the file to ease
the life for administrator. Also, ACL property may be versioned but only
the last version (for this revision) should be in effect during client
reads. Historical data on ACL is useful for the purpose of security audit.
Revision of the ACL property should not change the revision of the file
itself if we want to control access to historical data without changing
the data itself! Is that requirement is compatible with the current
implementation of versioned properties in SubVersion?
Summary: files inside repository has additional entity - revision number
as compared to ordinary file-system. Read-write
basic permissions on the files and folders in repository
should be extended/parametrized by revision numbers. That
would give a possibility to protect some historical data from
changing/viewing by unauthorized users.
Proposed realization:
ACLs are special properties on files and folders.
In this case existing clients should work without changes (or
massive changes). Except of file read/write permissions,
the permission to change ACL-properties should be implemented
also.
The implementation of ACL inheritance is the main performance bottleneck.
One of the possible ways is - ACL from the previous revision should be
copied to new revision during commit (not actually ACL but rather
reference to it). That will increase repository size but read
performance (taking into account checks against inherited ACL rules)
will benefit.
>
> 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
Best regards,
Igor Chub
mailto:chub@a-teleport.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 22 20:16:30 2004