Helge Jensen wrote:
> Branko Čibej wrote:
>
>> Helge Jensen wrote:
>
>
>> Note that a real ACL implementation can't use properties, for two
>> reasons:
>>
>> * 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
>> varsion.
>
>
> 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
> commits.
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
> interaction.
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.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Apr 27 07:38:30 2004