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