[cap-talk] More Heresey: ACLs not inherently bad
Sandro Magi
smagi at higherlogics.com
Thu Sep 18 15:01:40 CDT 2008
Jonathan S. Shapiro wrote:
> On Thu, 2008-09-18 at 15:20 -0400, Sandro Magi wrote:
>
>> Perhaps this is a bit naive, how is this not solved simply by
>> identifying facet ids with principal ids, and using a single process to
>> serve the repository? The repo can maintain its own mappings of facet
>> ids <-> group ids for group-based access control.
>>
>
> As I stated in the original note, implementing the SCM server is
> straightforward, and the implementation I had in mind is essentially the
> one that you are sketching.
>
> The problem is how, in the absence of global persistence, to allow the
> SCM server to re-connect to its tree without letting me (a user of the
> SCM server) do so.
>
> That is: in the absence of persistence we are going to end up with a
> layer where there is something that amounts to a shared global file name
> space (or equivalently, a shared global object space) and we will then
> face challenges with both re-establishment of rights on restart and
> enforcement of those rights.
>
Right, I was assuming persistence ala EROS, where the leaves of the tree
repo tree are EROS File objects. Your requirements stipulated efficient
ACL-like control in a cap system. This approach provide efficient local
ACLs in EROS.
Sandro
More information about the cap-talk
mailing list