Re: X and other visions

[Marcus Brinkmann]

Hi,

frankly, I can not follow you.  I told you we can revoke access to
capabilities, in the most flexible way, mainly on a per-task base.
The only semantically meaningful way to revoke access is either to
destroy the object and revoke all access, or to destroy access by
everyone except the current caller (io_revoke in the current Hurd).
So I am not sure what your concern is or what you want to patch.

However, I disagree with you about what is a common operation.
Revoking access is not common.  It is exceedingly rare.  The reason is
that usually you either hand out direct access to an object and forget
about it, or you need to keep tight control over the use of an object
and then you provide a proxy object.  I analysed all uses of objects
in the current Hurd on Mach, and that's how it is.  Revocation is
implemented, but not used at all.

Still, I opted to implement it in the cap library, because I see some
potential for it being used.  Mainly in allowing clients to provide
resources to servers, which then can securely revoke all of the
clients access to the resource to avoid security issues (my only
example so far is filesystem suid exec with user-provided task
object).  This is a very specific and rare application, but it sounds
useful enough for me to justify the cost of implementation.  The other
reason is that I am specifically not able to foretell if this feature
is required or not, and I don't want to touch that part of the code
later and add it :) Removing it is easier than adding it later,
because of the complexity of the code.

Thanks,
Marcus