[cap-talk] Capabilities and Freedom vs. Safety

[James A. Donald]

Jonathan S. Shapiro wrote:
 > If you proceed from these two assumptions, then the
 > "disable A's access" really *is* reducible to the ACL
 > problem, because you are trusting both B and B's
 > software.

The ACL solution needs to be applied to individual
programs, not just individual users.  Each user+program
combination should have its own ACLs.

Communicable permissions allow considerably finer
control than ACLs, but ACLs could cut a lot finer than
they do.

A big problem with fine grained control is that chmod
and the rest are already intolerably obscure for most
users, and slicing them finer would doubtless drive the
ordinary user completely up the wall if he had to employ
the existing tools and existing model of permissions,
sliced finer.   Microsoft has a fairly good solution for
end users to manage access control, and Bifrost has a
plan for dealing with the problem, though this plan has
yet to encounter actual users.

Both the Bifrost solution and the Microsoft solution
have the user selecting from a small set of sensible
options with workable default, rather than exercising
control in the full detail of which the system in
capable, though of course the Bifrost options slice
control much finer than the Microsoft options.

A solution that uses capabilities and nothing but
capabilities faces the same problem, indeed any pola
solution faces this problem, but Bifrost is the only
solution that has faced up to the problem of user
interface.  I don't know if it has solved it, but at
least it has thought about it.  In the case of Polaris,
a significant part of the horrible complexity and sheer
incomprehensibility descends upon end users, who are in
a hurry to get their job done, and do not want to deal
with all this crap.  They look for the "authorize
everything" button, and do not find it.

We cannot have chmod with an even longer string of even
more cryptic characters - that is classic bad unix user
interface.