Re: What's in a group?

[Marcus Brinkmann]

At Sun, 19 Mar 2006 22:15:17 -0500,
"Jonathan S. Shapiro" <address@hidden> 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