[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: ACL design question

From: Branko Čibej <brane_at_xbc.nu>
Date: 2004-04-27 07:35:42 CEST

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

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.