[cap-talk] More Heresey: ACLs not inherently bad

[Baldur Johannsson]

One idea to solve the original problem statement is to use nodes
(similar to gnu/linux
 fs3 i-nodes) that each have an list (which could just contain one
item) of sealed capabilities
to the "real" object in question. One type of these objects could be
an directory that map names to references to other nodes. Around all
this stuff are non-overlapping per user membranes that have unsealers
for the sealed capabilities in nodes. Those unsealers denote
privileges and or groups that particular user has or is part of to in
the shared graph.
Those who have the administrative privileges to denote who has access
to what have the sealers. For auditing those membranes can notify and
auditing logger of who accessed what when.

This is very similar to how identity based access control in EMonkey
worked. (AFAIK)

18. september 2008 Jonathan S. Shapiro <shap at eros-os.com>:
> 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.
>
This sounds exactly like the stuff that requires the pseudo-user
account hack used
for apache and the use of setuid. (That is, SCM has its own user
account and when invoked runs as that user)

But there is another solution to this proplem. It requires that the
fileserver (or the object persistence keeper) allow triggers that
start and hand over access to the SCM server to that object subtree
(if we have hierarchical namespace) when something tries to access
that object subtree for the first time and the SCM server (or what
ever it is that is started by the trigger) isnt already running. The
requester of access then just get handed an capability to the running
SCM server instance (or what ever it is that is started by the
trigger)

I hope I am clear enough in my writing, if not the do not hesitate to
ask for further clarifications.
-Baldur

PS. As I understand computing history Unix ACL system was begotten
exactly due to this proplem. So I prefer global orthogonal persistence
over that kind of spaghetti. (Though there is the update problem of
course but that can more easily solved than the problem stated above)