Helge Jensen wrote:
> Branko Čibej wrote:
>> Helge Jensen wrote:
>> Note that a real ACL implementation can't use properties, for two
>> * you have to be able to change the ACL of a historic revision
>> * ACLs must be attached to the path, not the node version (like
>> properties do), and more than one path can refer to the same node
> Could you elaborate on where/why this is nessesary? or point me to
> litterature on this.
I'd say it's obvious that you have to be able to restrict access to old
revisions, perhaps for security reasons, etc.
> I can envision a problem if you wish to limit _reading_, but I thought
> properties could do just fine for the WRITE scenario. Since you cannot
> change the historic versions, only commit new ones and here, then the
> "current" ACL (the set of acl:write properties on rHEAD) will apply to
Do note that there's much more to ACLs than read and write. One
interesting bit that you have to control is permission to change ACLs,
for example. I can imagine cases where you don't even want people to be
able to read the ACL. All this would be very hard to do with properties.
> "svnadmin setlog" seemingly does changes to old versions, but
> "svnadmin" should not be limited by any ACL.
svnadmin setlog does the same thing as "svn propset --revprop -rX
"svn:log" ..." and therefore access control applies. But note that this
changes revision props which are a different beast than file/dir props!
> A possible way to extend the property solution to cover the reading
> scnario would be to combine the HEAD and requested revision
> property,... I havent given it much thought since it has not been
> requested by my users yet.
Ouch. How do you handle renames?
> Note, that if i do an svn copy of something protected by an acl (I can
> only copy to a place where i have write permissions), I am able to
> remove the acl:write property on what I copied, which means I am able
> to "take ownership" of copies.
But only if you do that in the working copy, which means you lose the
O(1) copy complexity.
> The property solution works pretty well here. And people are able to
> give away permissions to each-other for any path where they have
> permissions themselves, it's really very low on administration
I'm sure it works for you, but it's far from flexible enough. I suggest
you take a look at the WebDAV ACL extension specs,
http://www.webdav.org/acl/. If that looks complex, rest assured that
it's just the tip of the iceberg.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Apr 27 07:38:30 2004