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

[Sandro Magi]

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.

Requirement 2 has a number of solutions, from policy configuration based
on wild cards, to extending the server with external policy consultants
for every file rev (or every writable file open).

This is easily represented in a capability system like EROS, and this
ACL design seems easily as efficient as any ACL system I know of. The
only downside is some additional storage in the server to maintain the
principal database, which I would think any ACL system would need to do
anyway.

Sandro

Jonathan S. Shapiro wrote:
> Let me try a concrete example, and let's see whether we can work through
> that one.
>
> We are trying to run a source code repository. We have two classes of
> users of the repository: documenters and developers. We also have a
> class of administrators who determine which users are in which class (or
> possibly in both).
>
> The desired policy is:
>
>   1. All users in either group should have read access to all source
>      files stored in the repository.
>
>   2. In order to revise a file whose name ends in .c or .h, the user
>      must be in the developer group.
>
>   3. Similarly, in order to create a directory anyplace *other than* the
>      "doc" tree, the user must be in the developer group.
>
>   4. We require that every revision be able to record the principal ID
>      of the responsible revisor.
>
>   5. We require that membership of the groups be alterable, and that
>      the effect of alteration applies to subsequent attempts to revise.
>
>   6. The reference repository tree has integrity requirements that are
>      assured by guaranteeing that the data set is only updated by the
>      software configuration management server.
>
> We are not concerned with proxying in this policy. If you agree to proxy
> for me, you are taking responsibility and sooner or later we'll fire
> your ass. The access control implementation is not required to implement
> the company's human resources department, though if you feel especially
> energetic we won't reject that submission. :-)
>
> Now it is perfectly clear to me that this policy can be implemented with
> capabilities very easily. This is true primarily because all decisions
> are made at open time and we have defined the key policy requirement as
> accountability tracing rather than access prevention.
>
> But in the absence of system-wide persistence, it is also clear that we
> need a way to capture the fact that the SCM server can touch the portion
> of the filesystem that stores the repository even though I (a user of
> the SCM server) cannot. That is where this is going to get hung up.
>
>
> shap
>
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>