[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What's in a group?

From: Jonathan S. Shapiro
Subject: Re: What's in a group?
Date: Mon, 20 Mar 2006 14:28:53 -0500

On Mon, 2006-03-20 at 11:31 +0100, Marcus Brinkmann wrote:
> > 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.

Yes, I agree that a schedule is also needed, but no, you do not need any
additional services to "manage" this. If I wish to create an object
usable by the group, I use the group's storage and schedule, and then
bind a capability to the resulting object into the group's directory.
This includes subdirectories. Once I place the new object into the group
directory, other members of the group can use it.

Management may be helpful to assist programmers in getting the idiom
correct (which is important), but they are not functionally required.

> 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!

Me too, but the mechanism that I have described is sufficient to support

> 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").

I can see that this would be a possible way to "package" the discipline
that I have described. It would help to avoid certain types of errors.
The main concern I see with it is that it builds a stronger "barrier"
between the stuff managed by the group and the stuff managed by me, and
that isn't always what I want.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]