Re: X and other visions

[Marcus Brinkmann]

At Wed, 16 Jun 2004 21:19:43 +0200,
Bas Wijnen wrote:
> 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".

I don't like this.  It makes the object model much more complex
without any semantical gain.  In fact, it muddles the semantics.
Also, there is nothing you can do with this that you couldn't do with
the current semantics, and it's totally unclear what the performance
impact is either way.  Maintaining that parent-child relationship
(which can evolve into a completely arbitrary graph) can very well
totally destroy any performance gain you are hoping for, and badly
hurt the common case.

There are different strategies you can apply for shielding access to
objects.  Beside the proxy object idea, another solution is to derive
child objects and capabilities from a master object, and pass that
around.  Revoking that would require the master object.

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

Right.

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

Well, sharing the same object is actually not a good idea here.  You
are reminding me here that if one caller can revoke, then every other
can, and that is correct.  So, gdm can not share the object.

> If it cannot, then gdm must act as
> a proxy,

Only if you stick with the proposition that gdm must control this at
all.  It could just be the user of a higher-level controlling entity.

> resulting in slowness and extra memory usage.

Programmers are notoriously bad at predicting the performance of their
programs.  It's not obvious at all that a proxy object would be too
slow or even just slower than what you propose.  In fact, I have some
ideas why it could be the other way round, but we wouldn't know before
trying.

> What I think gdm "wants" to do is revoke access for all clients which
> were copied from its own object.

What gdm wants to do (assuming it is the entity exercising control) is
to give its children a different capability from the one itself
possesses, and that means a cap to a different object (either proxy or
server-implemented).

Here is our model: We do not distinguish between capabilities.  We
distinguish between objects.

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

In Hurd on L4, the server is always involved when a capability is
passed from A to B, this is a requirement due to the way L4 is
designed.  However, it is a transparent process: The server will
always accept the transfer.  I fundamentally agree with the
proposition that the server should not exercise any control over how a
capability is passed around (as clients holding the cap could just as
well act as a proxy, so there is no gain).  However, I do not believe
that capabilities to the same object should be distinguished.

See, there are systems which "tag" a capability to indicate which
operations are permitted (read/write/execute for a file, for example).
This is not how we do it.  We instead create a new object and a new
capability to that object.  Now, if you are worried that a proxy
object is harming you, you can implement support in the server for
"derived" objects to which you pass a capability to untrusted users.
This requires support in the server, but so does any tagging (which
must be checked and enforced by the server).

Tagging and parent-child relationships are very specific forms of
capability-differentiation.  They have very specific applications.  I
could also say they are too specific.  Creating a new object is a
totally flexible operation, which covers semantically all our needs.

Let's worry about performance when we lack it.  There are very
specific optimisations you can do to avoid overhead, which don't
require such an intrusive change as an extension of the capability
model.

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

Specific scenarios are always good to test your theories.  However,
you shouldn't focus on a single scenario.  Your gdm example is way to
vague to make a definite statement.  However, let me point out that
the problem is remarkably similar to that of sessions in a shell (the
controlling terminal acts as the soundcard here).  And we all know
that job control under Unix sucks.  So why emulate it?

If we imagine a management layer that multiplexes console users to
console hardware, then I'd think that one solution would be to
implement this whole session management into this management layer,
not gdm.  In fact, I would destroy the whole session, including gdm,
after log out and create a new "virtual console" in the management
layer for a new gdm.  Note that nothing says you need to destroy the
session: With such a design you could also "detach" a whole login
session and start a new one int he foreground (and later switch
between them).

Thanks,
Marcus