[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: Ph. Marek <philipp.marek_at_bmlv.gv.at>
Date: 2004-04-27 10:49:02 CEST

> >> 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
Received on Tue Apr 27 10:49:38 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.