On 25 Mar 1997, Jason L Tibbitts III wrote:
> For the kind of gross categorization I was talking about, these are just
> list owners. But for actual administrative duties you wouldn't want to tie
> that to users, anyway. You'd want to tie it to passwords. Ideas for
> password stuff:
Well, I've seen listproc tie it to passwords and users -- for "double"
protection. But when I've changed e-mail accounts, all I did was telnet to
port 25 and that took care of the user protection. And I think it adds too
much complexity in.
> 1. The current (testing) scheme; several passwords, each with a security
> level. All security based on required level <= password level.
> 2. A class scheme. Passwords tied to classes of things; a valid password
> in a class can perform that class of actions. Give several passwords
> and let list owners choose what they do.
> 3. Some scheme based on the access restriction we talked about.
> 4 - oo. Things I haven't thought of that you're going to cook up for me.
Note: When I mention a person, I actually mean a person (or people) who
have a password for that function.
Well, I like the idea of having the majordomo-owner give the
list-owner a master password to the list. Basically, the admin password as
it exists now.
With this password, the list-owner should be able to create security
classes for the list (5?) that can have different functions, among a
group of possible that we supply. Namely, the functions would be:
1. Viewing config file settings
2. Changing config file settings
3. Changing a specific config file variable (or group of them; like only
the description and get and index variables)
4. Adding subscribers
5. Removing subscribers
6. Viewing the subscription list (who or which overrides, basically)
7. Approving or deleting tokens for message approval
8. Changing subscriber settings
9. anything else I left out
Thus, I could create a subscription manager class. ANyone with the
password for that class could do anything I let them, which would probably
include #4,5,6 and 8 from above. I might also let them change the
subscription and unsubscription variables in the config file.
My archives manager class would only be allowed to use #8 (maybe for
changing the user's digest settings) and a limited change in the variables
in the config file for get and index.
My edit class would only be allowed access to #7.
> BR> Personally, I don't like automatic list creation simply because I don't
> BR> want other things fooling around with my aliases file. If OTOH, it
> BR> simply created a file that I could insert into my aliases file, that's
> BR> a different story.
>
> To each their own; I suppose it could do several things:
>
> 1. Disallow list creation altogether.
> 2. Handle list creation all by itself, given an alias file it can scribble
> in. (I don't want to think about the non-Sendmail issue right now.)
> 3. Do everything it can with its own files (make directories, set up
> databases and configs) and mail the installation owner the aliases to
> add.
> 4. Create lots of numbered lists.
Looks good.
-------------------------------------------------------------------------
| Brock Rozen | brozen@webdreams.com | http://www.webdreams.com/~brozen |
-------------------------------------------------------------------------
References:
|
|
