At Sun, 19 Mar 2006 22:15:17 -0500, "Jonathan S. Shapiro" <[EMAIL PROTECTED]> wrote: > First, I think that Marcus has the semantics *almost* right. He has left > out the third requirement for conventional groups: > > 3) Mere membership in a group should not convey the authority to > add a new party to the group. > > We need to look at that statement and agree that it is nonsense. If I am > in a group, I can proxy for you cheaply. This is *especially* true in an > IDL-based system, where the proxy agent can be completely generic. > > This meant that there is no security motivation for preventing member A > from adding a new member B.
But this is only true if A can already communicate with B at all. This means that another part that potentially requires an administrator is to set up the initial communication channel between A and B. It is true that users can communicate transitively. If we want to exploit this, we can model a very simple "communication grouping" mechanism: The users of the system are organized in disjoint sets. Any member of a set can communicate with any other member of the same set. However, from an administrator point of view, this is probably not the most convenient way to organize users, and there may be other parameters in the system configuration that ask for finer distinctions (for example, which users can log onto which hardware terminals). So, I would actually expect a real world mechanism to be more featureful. It's a challenge to convey the information who can communicate in a user interface so that the administrator does not accidentially compromise something. However, for the Hurd, I think the common scenario is that everybody can communicate with everybody else, except for isolated subsystems (like virtual domains) and special services (ftp server). > Actually, that is really a pretty nice thing, because it means that we > can reduce a group to a pair of capabilities: > > 1. A capability to a source of storage, with the intention that > this can be used by any member of the group. > > 2. A capability to a directory object that holds all of the objects > that the group needs to share. > > That's it. The only part of this that potentially requires an > administrator is if this storage has to be independent of the users. The directory object requires a schedule. Also, the storage by itself is useless, you need a service to manage it. So, there may also be a file server (for example), also requiring a schedule. By extending the idea, you really give the group a storage and a schedule resource, and a default configuration. Up to this point, we called such a constellation a "user". Note that this is not an abstract argument: I find running different group owned programs beside a directory and file server useful, especially in a multi-server object system! I guess this means that I am proposing that a group is just another "user", but with a different default configuration, and with special semantics associated with it (read: there are high-level policies in the admin config tools and user's shells that know how to deal with "groups"). Who gets access to this special "user"? The group owners. The group owners can then further restrict the use of the resources, for example by running a file and directory server, and only allow access to these. Then they pass the desired capabilities to the other members in the group. Sometimes the group owner may be the administrator, but it can also be a technical assistant, or the project leader self. New groups can also be created by users themselves, on their own resources, using exactly the same mechanisms, without the administrator becoming involved. I think that's a very powerful idea. The challenge is in creating useful defaults, and making the degree of freedom manageable. In any case, the administrator gets involved in these steps: 1) Allow communication between members in the group (capability exchange). 2) Allocate resources for use by the group owners. The group owners engage in the following activities: 1) Set up the group services. 2) Provide the group services via capabilities to the members of the group. Thanks, Marcus _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
