John Peacock wrote:
> Branko Čibej wrote:
>
>> John Peacock wrote:
>>
>>> I would assume that the ACL work will likely be implemented as a
>>> special form of property, and deal with inheritance in the tree.
>>
>>
>>
>> I think you assume too much. That is one possible model for ACL
>> implementation, but even that would differ significantly from
>> inheritable properties in that you have to be able to modify ACLs on
>> historical revisions (e.g., lock most people out from everything older
>> than r1524 in path /foo/bar because it contains sensitive information).
>
>
> An ACL should be associated with a given node (be that directory or
> file), be versioned, and have a well-defined inheritance scheme. In a
> basic sense, the first two correspond closely to what a property is
> currently, or am I missing some deeper meaning. I hadn't considered
> an ACL being applied back to an earlier rev, but it still looks like
> editing an attribute of a given node in the tree.
Ah, but you want to be able to track such changes. :-)
IMHO one of the big mistakes we're making now is that we allow changes
to revprops without an audit trail, i.e., it's impossible to tell
_from_the_repository_ when ta revprop was changed, who changed it, and
what the previous value was. That's a naughty thing for a version
control system to do.
> By "dealing with inheritance" I was thinking more about whether the
> /server/ would determine the applicable ACL for a given file or
> whether the /client/ would have to walk the tree. I would think that
> obviously the former would be preferrable from a performance (as well
> as security) standpoint.
There is no question in my mind that the server has to do all the ACL
processing and authorization checks. And security is more important than
performance in this case.
> Once a general mechanism exists for the server to report derived
> attributes (based on information in the tree not associated with the
> specific file/dir), extending that to work for both ACL's and other
> inherited attributes should be much easier.
Oh, there's another reason why ACLs can't be trivially implemented as
properties -- it should be possible to prevent principals from even
reading the ACL.
Hm. Actually we'll need access control on properties, too. What fun.
Oh yes, and properties belong to nodes, not paths; the same node can be
visible by different paths and inherit different ACLs. What fun indeed! :-)
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 2 00:22:58 2004