What's in a group?

[Marcus Brinkmann]

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