Re: X and other visions

[Bas Wijnen]

Hi,

On Wed, Jun 16, 2004 at 05:39:37PM +0200, Marcus Brinkmann wrote:
> 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.

I would expect an other way to be much more common, I'll explain below.  The
patch would mostly consist of the inclusion of a "parent" capability object
pointer in every capability object, and a call to "revoke all children".

> 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.

I didn't mean revoking was a common operation, but that wanting tight control
is usual and not needing to be a proxy for it would speed things up in that
situation.

An example situation:
We have a sound server, which deals out capabilities to make use of a sound
card.  Let's say the session manager (gdm or something) has one, and it'll
auto-copy on fork, so when logging in (locally), all the processes have a copy
of this capability.  A tree of how they get it:

gdm
  gnome-panel
    gnome-terminal (launched from panel)
      bash
        some_backgrounded_application
(of course there is much more, but it isn't relevant here.)

Now if the user logs out, all programs above except
some_backgrounded_application and gdm will be closed.  Gdm does not know about
which applications are still running, but it wants to stop them using the
capability anyway.  It cannot use the normal process groups for this, because
capabilities can have been copied cross process groups.

If I understand you correctly, you expect gdm to destroy the capability
object, thereby implicitly revoking it for all clients, and then getting a new
one for the next session.  While this is possible, it doesn't sound "right" to
me.  First of all, if gdm can revoke it while it is still used, then others
can as well, which in this example means any application could terminate all
sound output for the rest of the session.  If it cannot, then gdm must act as
a proxy, resulting in slowness and extra memory usage.

What I think gdm "wants" to do is revoke access for all clients which
were copied from its own object.  If that is allowed, then any application can
terminate sound output for the rest of the session, for all programs that it
spawned.  That way, giving a capability to a not-fully-trusted task is not a
problem.  Well, it can still (ab)use the capability of course, but it cannot
influence other tasks' use of it.  That is a Good Thing.  Still it is possible
to end a period where a capability could be used by a certain client, without
destroying it completely.

The reason I don't want to destroy capabilities is that I very much like the
idea that you can only get a capability from someone who has it and wants to
give it to you.  The server doesn't need to give out any capabilities (except
one at startup), and therefore doesn't need to get involved into security
issues about when a task is allowed to receive a capability.  I get the
feeling this is not how you were planning to do it.  As far as I can see,
revocation of "all children of a capability" is very much needed for it.

The task server (and maybe some others as well?) will give out capabilities
anyway, but those are capabilities for which no priveledges are required to
get them.

I would like to hear how you think a situation such as the example above (a
session manager giving out a capability for a resource for a limited time)
should be implemented, and why it is (or isn't) better than the solution I
proposed here.

Thanks,
Bas

-- 
I encourage sending me encrypted e-mail.
Please send the central message of e-mails as plain text in the message body,
   not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
for more information, see http://129.125.47.90/e-mail.html

pgpvX3yQsejds.pgp
Description: PGP signature