> After reading your essay and email, the Saltzer paper, and Hardy's
> sound bites, I have a follow-up question regarding your phrase
> "I can't go the other way around.", but I'll defer it for another email
> another day.
Greg:
I won't spoil the fun of thinking it through by giving away the answer, but perhaps you might find a test problem or two helpful. If you can solve these, you'll have shown that ACLs and capabilities are really equivalent.
>From a purely theoretical standpoint, neither problem is solvable.
Given minor surgery to the ACL model, the first problem is
theoretically solvable. The second, as far as I know, is not. I am
not aware of an engineerable solution to either problem.
Don't let yourself get too frustrated.
Scenario 1:
Consider two processes A and B. A is a client application, and B is a
supporting component that A wishes to create and then use. If you
like, imagine that B is something in the style of an ActiveX control.
Imagine that A has authority to manipulate objects W, X, and Y (our
sample user hasn't created many files yet). It wishes to grant to B
the right to access X, but not W or Y. In addition, it wishes to
ensure that B never gains access to subsequently created objects Z,
Z', Z'', Z''' etc.
Challenge 1: Describe a conceptually sound solution to this problem
using only ACLs.
the key element(s) of your solution.
Challenge 2: Design an *efficient* primitive mechanism to implement
Scenario/Challenge 2:
Describe how to implement the UNIX passwd program within a purely ACL-oriented model. Remember that the setuid mechanism in UNIX and the program privilege table in VMS are bolt-ons -- they step outside the ACL model.
shap