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

[Marcus Brinkmann]

At Mon, 22 Sep 2008 10:13:00 -0400,
Sandro Magi <naasking at higherlogics.com> wrote:
> It's only required for an "initial authentication" step. From then on
> you have the choice as to whether to use ACLs or just caps depending on
> what's appropriate, and the underlying system still operates via caps.
> Also, the ACLs are isolated to a particular subsystem, and use of caps
> is encouraged since the "useless" ACL parameter must be passed around
> for every call. If a solution cries out for ACL-type access control, I
> think that's a fair trade off.

In the GNU/Hurd, users get "authenticated capabilities" to objects.
The capability is associated with principal IDs in the server (see my
other mail as to how this happens).  This means that many capabilities
can refer to the same underlying object, for example a file, but each
of these capabilities can have different principals associated with
them.

That way you never need to pass ACL parameters in normal calls.  A
"reauthenticate" call is provided which allows to request a new
capability to the same underlying object as another capability, but
with different ACL data (assuming that the protocol explained in the
other mail demonstrates that the caller has the required authority).
Calls to "plain" capabilities and authenticated capabilities are
syntactically identical, and it is the server's discretion to use the
authentication data or not.  Simple servers could not implement the
reauthentication method at all (or make it a dummy function) without
breaking things.

Reauthentication is an extremely powerful notion in the context of
POSIX compatibility.  For example, in the GNU/Hurd it is possible to
send a new capability to the ACL server to a process using a signal
message and have it reauthenticate all its file handles, for example
to elevate the privileges of your text editor so that you can save a
file that you edited in core with read-only access under the previous ID.

Thanks,
Marcus