Hi, I was pondering how to do terminals and sessions lately, and have stumbled upon a semantically tricky issue I want your input on.
Managing users in isolation is rather straightforward: At creation, a new user session will be constructed, for example from a template or a template description. Then some authentication token will be inserted (can be a public fingerprint, for example, a la "authorized_keys"). That's basically it. But what corresponds to the Unix group concept? I have identified two semantic uses for a "group": 1) Sharing information and authorization. Ie, allow communication among users of the same group. 2) Provide durable storage that is not associated with any particular member of the group. To fulfill the first requirement, a group should for example contain some shared mutable name space, like a directory, that can be accessed by all users. To fulfill the second requirement, this shared name space should be allocated not from any user's resource pool, but from its own resource pool, the resource pool of the group. This is required to make the storage durable, even if some members of the group are deleted from the system. The second requirement can go away if we elect one user to be the "group owner". Destroying the "group owner" would then implicitely destroy the group. This may be an acceptable policy. Groups that should not be owned by any particular user can be owned by the system administrator or dummy users (for example "faculty" users or "project" users). This makes groups a mostly user-implemented concept. The "group owner" provides the "group" as a service shared by all members of the group. Then the only remaining question is what mechanism the system needs to provide to support that (beyond normal RPC and resource management) and in what way the system may want to restrict this. Because the group itself is in this scenario a user-space object, the only thing that the system needs to allow in the first place to make this work is the communication between different members in the group, or rather: communication between the group members and the group owner (the rest follows transitively). This is also what one may want to control with the system policy in the first place, a nice coincidence that is not by chance :) So, adding a member to a group actually means, for the sysadmin, to allow communication between the member and the group owner. The rest can be done by non-system code. Thoughts? Thanks, Marcus _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
