Re: ACL design question

Branko Čibej wrote:

> Helge Jensen wrote:
>> Branko Čibej wrote:

I appreciate the time you've taken to comment on my solution.

>>>> Note that a real ACL implementation
[...]
>> I can imagine cases where you don't even want people to be
>> able to read the ACL.

OK, so "real" here means an implementation that can prevent much more
than reading or writing the protected content, but can also protect the
ACL itself and whatnot.

>> Could you elaborate on where/why this is nessesary? or point me to
>> litterature on this.

Thanks for your pointers.

> Do note that there's much more to ACLs than read and write.

Possibly,... depends on what you want to protect.

> One
> interesting bit that you have to control is permission to change ACLs,
> for example.

That's actually nicely covered by my property solution, you can change
ACL if you can commit changes to the parent path.

While this may be primitive, it has the advantage of being
understandable and existing today :) It also seems to work for people.

> 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.

OK

> 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!

OK, so there may be a need for ACL'ing revprop changes. This could be
done in a number of ways, but it doesn't need to have much resemblance
to the way ordinary changes can be ACL'ed. (for example, it could be a
hard-coded list of users in the pre-commit hook, or the HEAD revision of
an "acl:revprop-write" on the "" path, allowing you to see how it was in
the past).

Or a finer granularity may be required. It doesn't seem like the two
domains have much in common wrt. _how_ they should have access controlled.

>> 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?

First, as I said, I haven't started thinking to deeply about limiting
read, since the need has not been there yet.

Renames could pose a problem when the "HEAD" dissapers... I don't really
know. Perhaps limiting read requires a different approach than limiting
writes?

It may be, that the "lastest rev. that contains PATH to be checked"
would work instead of "HEAD", ... possibly... (even though that would be
an expensive calculation in SVN right now).

>> 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 copy is still O(1), but any change to the ACL requires a commit.

An ACL change is only needed if i have changes to commit to the copied
stuff anyway, and "taking ownership" amounts to "svn propdel acl:write"
on the limiting path.

So it's not too bad... output of trying to commit without
taking-ownership is something like:

...
/foo/bar/baz: commit denied by acl:write at /foo/bar

So it's pretty easy to spot what to change in your working copy.

hmmmm... maybe i should even output the relevant SVN commands for taking
ownership, ready for cut'n paste....

> I'm sure it works for you, but it's far from flexible enough.

OK, I wasn't proposing it as "the solution to be chosen for SVN", merely
as a way you can do ACL's (and get started using it today ;). But I
thank you for the time you've taken to comment on it.

It really rocks here where we are ~15 devels, some sharing code and some
paranoid that someone else should destroy their work by commiting in
"their" modules :)

> I suggest
> you take a look at the WebDAV ACL extension specs,
> http://www.webdav.org/acl/.

Maybe i will, thanks for the pointer and input.

> If that looks complex, rest assured that
> it's just the tip of the iceberg.

I think i'll stay on my small ice-cube for now. Can't be much of such a
small cube that's unseen under the water :)

-- 
Helge
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org