(Message inbox:385)
Return-Path: <spm>
Received: by mit-theseus (4.12/4.7)
	id AA08599; Thu, 3 May 84 17:40:51 edt
From: spm (Steve Miller )
Message-Id: <8405032140.AA08599@mit-theseus>
Date:  3 May 1984 1740-EDT (Thursday)
To: dgg (David G. Grubbs)
Cc: doug, nancy, spm, lbm
Subject: Re: Spec for acct_mgr routines.
In-Reply-To: Your message of 3 May 1984 1551-EDT (Thursday).
             <8405031951.AA29964@mit-theseus>

Some feedback on your excellent specs-

Under assumptions, the groups are defined in the database by the
Athena staff (athdba), and the initial account administrators are
defined.  The list of other members need never come to the athdba,
since the administrators can create it themselves.

The "delegation" should only add another user as administrator,
not undo the current administrator.  And on general software
principles, you need to be able to "remove" an administrator.
Only the master administrators, defined by the athdba, or the
athdba can add or remove administrators.  Thus, for example,
the Prof is designated as the master account administrator,
and at the beginning of each term adds the teaching assistants as
account administrators, and undoes the previous term's ta's.
(This also means that the Prof has to know something, or ask
the athdba to do it.  But either way, someone has to make do a
conscious act to cause it to happen.)

There can be multiple account administrators for a project,
and multiple masters, e.g. 2 principle investigators.

List members by group-
Since we are defining the data base as publicly readable, I
believe anyone should be able to list any group. (any objections
out there?)  Therefore I claim all the stuff regarding the
users id (running the program) for this is not needed.

Delegate-
The data base can distinguish between two types of account
administrators- masters and those delegated by the masters.
If you freely allow delegation, there are no controls on
how far it can go, and no easy way for someone in charge
(the P.I.) to undo it.

So, the check is to see if the person invoking it is a
"master" administrator.

The other important aspect to note is that the commands
don't do anything to the database locally, but communicate
via the network to a server process that actually does all
the work on the database.