Re: Server granularity

[Jonathan S. Shapiro]

On Sun, 2005-10-16 at 20:40 +0200, Marcus Brinkmann wrote:
> This is true.  More specifically, a single server serves many objects
> to (potentially) many different clients, which belong to (potentially)
> many users.
> 
> One reason for this design is that it enables sharing.

This statement makes no sense to me. Sharing is performed at the level
of objects, not at the level of servers.

If you are concerned about security at all, you want to be able to be
very explicit about when and how sharing happens. This does not mean
that you want to prevent sharing, but it does mean that you (the user)
want to be in charge of it.

> In POSIX a shared
> resource will survive if any of the holders of the resource
> terminates, even if they are killed with "kill -9" (which I interpret
> as: The task is not allowed to execute even a single more instruction).

In EROS/Coyotos there is no problem with this. It is purely a function
of whether the storage source survives.

In POSIX, what you say is not entirely accurate. Whether a resource
survives depends on the resource and the usage model for that resource.

> The process server: One process, many objects.  Beside the process
> list, the process server provides the namespace for message ports:
> Message ports are used to send signals directly to the process.  If
> you have resource accountability, there is no pressure to have a
> global process space that can be utilized by the system administrator
> (the admin can just revoke the resources).  But if you want
> process-to-process communication (signals), you need some shared name
> server for that.

You absolutely do *not* need a shared name server for this. The only
thing a shared name server can accomplish here is to let messages be
sent between parties who are not authorized.

You *may* need a name server -- I'm not even convinced of that -- but in
a robust system you definitely do *not* want a globally shared name
server. This is one of the foundationally wrong decisions in UNIX.

In the end, my problem with the design that you propose is that KeyNIX
provided UNIX compatibility without doing any of this kind of sharing.


shap