Re: X and other visions

[Bas Wijnen]

On Tue, Jun 15, 2004 at 08:29:53PM +0200, Marcus Brinkmann wrote:
> At Sun, 13 Jun 2004 19:43:14 +0200, Bas Wijnen wrote:
> > 
> > Suppose we have a system in a classroom, as described below.  At (local)
> > login, a capability for the sound card should be given out.  At logout,
> > this capability should be revoked, including all copies made of it.  This
> > to prevent the user from setting up a server in the background enabling
> > him or her to use the sound card remotely.
> > 
> > Does the capability library have a system for that?  If not, can it easily
> > be implemented in the server using the lib?  I think it should be in the
> > library,
> 
> There is a lot one can say about this, and it is all interesting and
> relevant.  However, one should not lose focus.  The application you mention
> is just one specific possible scenario.

It was meant as an example of a very usual scenario, where when a capability
is revoked, all copies which are made of it are revoked as well.  Actually, I
cannot think of a situation where the server would want to revoke a capability
but not its copies, because as far as the server is concerned, they are equal.
If a client drops its own capability, it may want to keep the copies intact.
In that case the copies should get the dropped capability's parent as their
new parent, so they are still properly revoked if one of their ancestors is.

I'm currently trying to understand the API of the capability lib (and writing
some documentation about it for newbies) so I might write a patch to make
clear what I mean.  I don't think it's a big patch, but it does change the
interface so if it's accepted then the sooner the better, I'd say.

> First, this has almost nothing to do with capabilities.  Capabilities are
> managed by the server, and he can revoke access to a capability object on a
> per-task base.  This is all you need to implement such functionality.
> Either by allowing a login session manager to revoke the access, or by
> revoking the access yourself if you act as a proxy between the system and
> the user.

Because I think it will happen all the time, I think it is bad if the client
must be a proxy to implement the functionality.  That requires resources
(memory, but also processor time, because the use of the capability costs
extra IPC operations.)  If it would hardly ever happen, that wouldn't be a
problem, but it is very unlikely that capabilities are ever revoked while
their copies stay active.  If you think otherwise, please give some examples.

> So, let's put the cap system aside.  The cap system's
> funcationality is very low level, and it tells us almost nothing about the
> specific issues with sound and the console.

I completely agree with your points about sound cards.

> In any case, the cap system is flexible enough to allow all this and more.

I know it can handle it, but for the most common operations it should also be
as fast as possible.

Bye,
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

pgph3bRy9M_U6.pgp
Description: PGP signature