Sam Mason wrote:
On Tue, Dec 08, 2009 at 02:08:18PM +0200, Bahadir Balban wrote:
To your ambient authority argument, wikipedia reads:
The authority is "ambient" in the sense that it exists in a broadly
visible environment (often, but not necessarily a global environment)
where any subject can request it by name.
"
This is not true for this case, since designation, authorization and
ownership information is all bundled in the capability structure and
gets checked on each operation.
It depends on the level of abstraction you're thinking about. Within
codezero a single process can exercise all authority in error because
the kernel checks which capabilities determine whether an operation has
enough authority to proceed. When the capabilities are directly exposed
to the process it's "harder" for it to go wrong because the code is
directly naming the authority needed for every operation.
Admittedly this is a qualitative appeal rather than a quantitative one,
but I don't possess the experience to argue the point in any other way.
I thought that once a process has a certain capability, it doesn't
matter how it is invoked. It may be explicitly by a capid, or
implicitly. Keeping the existing L4 interface was highly desirable for
design reasons so I implemented it this way.
I didn't get how a process would exercise authority in error. If you
start the process with a single capability, it may try all it wants with
the syscalls. It will always end up with an -ENOCAP error unless it is
that very operation that corresponds to that possessed capability.
When you say the code is directly naming the authority you are
approaching it with a pure capability way of thinking. It is doing that
because it comes natural to name entities with their direct name when
you get to use them. I believe this is more practical. While this might
be an issue on a capability way of thinking, I think it is an
aesthetical one, security-wise it seems to me that they are no different.
--
Bahadir Balban
