[cap-talk] CapDesk demo, capability demos in general

[Jonathan S. Shapiro]

On Sun, 2007-10-07 at 07:45 +1000, James A. Donald wrote:
> For some permissions, ACLs really are the best solution.
> For example one wants the package installer to have
> authority that cannot be granted to any other software,
> not even by the system administrator, short of booting
> up a different environment...

James:

I agree with your statement about permissions held by the installer, but
I see no difficulty of implementation if this is achieved by designing
the installer to hold initial capabilities that are not accessible to
the administrator's account. Conversely, I see a number of difficulties
if such a scheme is implemented by ACLs, because administrators
generally *are* in a position to manipulate the content of ACLs in
general.

Can you articulate what it is about ACLs that you believe makes them
well-suited to this problem? Also, can you articulate how my concern
about the use of ACLs for this application can be defeated?

Perhaps it will surprise you, but I actually do agree that there are
places where ACLs are a better solution (I can hear the cries of
"heresy" ramping up already). I don't think this turns out to be one of
them in practice.

>   For other permissions,
> particularly transient permissions such as permission to
> bring up a dialog box, communicable permissions are the
> best solution.

Hmm. Taken together, your two statements seem to imply that a
two-mechanism system might be worthwhile. If so, I suggest that it must
be a logical AND rather than a logical OR. That is: if both ACLs and
capabilities are used, BOTH must permit the operation in question in
order for the operation to proceed.

The problem with either-or systems is that things slip through the
cracks where (a) the two systems have been configured in subtly
different ways, or (b) the overlap in what the two systems can express
is imperfect.

We have seen a lot of concrete evidence supporting this concern over the
history of UNIX.


shap