ACL design question

["Henderson, Michael D" <mi...@lmco.com>]

Is there an issue on adding access control support to subversion, or maybe a document outlining the design approach that may be taken? ACLs or roles/groups?

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

Re: ACL design question

["Ph. Marek" <ph...@bmlv.gv.at>]

>  >> 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.
I apologize for not reading this whole thread; I just took a look into this 
thread.

May I suggest using a similar system as used on smartcards:
Every file A has a pointer to a file B, which stores A's acls, and this 
pointers may be self-referential and circular.

So:
File A is protected by ACL B
File B is protected by ACL C
File C is protected by ACL C

B: everyone read, group X write
C: group X read/write

So A can be read by everybody, group X may write and change permission.

I'd propose defining a directory in your repository (or one directory per 
project), and storing permission files with acls in there.
And the relation of ACL to file is done with a per-file-attribute, eg. 
dav::acl.

I believe you'll find documentation for this on the internet, if my 
explanation proves too short :-)


Regards,

Phil

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

Re: ACL design question

[Helge Jensen <je...@slog.dk>]

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

Re: ACL design question

[Branko Čibej <br...@xbc.nu>]

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

Re: ACL design question

[Helge Jensen <je...@slog.dk>]

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

"svnadmin setlog" seemingly does changes to old versions, but "svnadmin" 
should not be limited by any ACL.

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.

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.

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.

-- 
Helge

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

Re: ACL design question

[Branko Čibej <br...@xbc.nu>]

Helge Jensen wrote:

> Henderson, Michael D wrote:
>
>> Is there an issue on adding access control support to subversion, or 
>> maybe a document outlining the design approach that may be taken? 
>> ACLs or roles/groups?
>
>
> I've implemented simple ACL's using properties, for WRITE only.

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.

-- Brane



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

Re: ACL design question

[Helge Jensen <je...@slog.dk>]

Henderson, Michael D wrote:
> Is there an issue on adding access control support to subversion, or maybe a document outlining the design approach that may be taken? ACLs or roles/groups?

I've implemented simple ACL's using properties, for WRITE only. it's 
some time ago, and could probably be rewritten using the new 
"authz_func" arguement to svn_repos_dir_delta, possibly you could also 
limit the reading to logged in users using that.

When commit'ing, the pre-commit hook traverses the commit with 
svn_repos_dir_delta.

Let write_list(path) be:
   - preset (in the code for now) if path == ""
   - the acl:write property of path, if it has one
   - write_list(parent(path)) otherwise

Then commits by user U are denied if any of the following occur:
  - change/prop_change FILE with U not in write_list(file)
  - add/delete/prop_change PATH/ENTRY with U not in write_list(PATH)

This scheme has some nice properties

   * it's revision-controlled, so you can see when and who revoked your 
permission to write by inspecting the log

   * It requires no "external" (to svn) setup or storage, except the 
setting of write_list("")

   * It allows you to take ownership of anything you copy (but you STILL 
can't commit to the original path!)

For identification, i use the SVN login names, and I added the 
"unix-groups" concept, for "@group" in acl:write. (all sorts of other 
fancier schemes can be thought of... but my users of SVN are also UNIX 
users on the server.

Have a look at http://svn.slog.dk/repos/+svn/py/acl.py, which is 
probably outdated, since it uses some low-level functions... but it 
works for me, and has done for >5 months.

-- 
Helge

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

Re: ACL design question

[Branko Čibej <br...@xbc.nu>]

Henderson, Michael D wrote:

>Is there an issue on adding access control support to subversion, or maybe a document outlining the design approach that may be taken? ACLs or roles/groups?
>  
>
I'm working on this, and expect to have a draft ready soon.

-- Brane



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