LSTSRV-L Archives

LISTSERV Site Administrators' Forum

LSTSRV-L

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Paul Russell <[log in to unmask]>
Thu, 12 Aug 2004 15:56:56 -0500
text/plain (77 lines)
As an organization grows, it often becomes necessary to delegate selected
administrative responsibilities for some services to individuals scattered
throughout the organization. The current privilege class structure in
LISTSERV makes it virtually impossible to grant selected administrative
privileges to an individual without granting full administrative privileges
to that individual. At present, LISTSERV recognizes five classes of
privileges:

        Postmaster (site administrator)
        List owner
        List editor/moderator
        Subscriber
        Public

At the very least, there should be a sub-postmaster class immediately
below postmaster, and the postmaster should be able to specify the
privileges which should be granted to each individual sub-postmaster.

Generally, administrative tasks fall into a few categories, for example:

        1. Create new lists;
        2. Manage existing lists;
        3. Manage user access using 'pwc', 'serve', and related commands; and
        4. Manage site-wide settings and templates.

There may be others, but these will suffice for this discussion.

It should be possible to grant privileges associated with a specific
category to an individual sub-postmaster without granting privileges
associated with any other category, and it should be possible to grant
privileges in different categories to different individuals in the
sub-postmaster class.

Commands such as 'pwc' and 'serve' should be restricted in a manner that
recognizes the access hierarchy, i.e., a postmaster should be able to
issue these commands for any address, but a sub-postmaster should not be
able to issue these commands for a postmaster or sub-postmaster address.
(Related issue: The 'serve' and 'pwc' commands should require the individual
administrator's password, rather than the CREATEPW or STOREPW.)

There should also be a way to define groups of related lists, so that
Category 2 (list management) privileges can be granted for all lists
on the server, or for specific groups of lists. For example, central
Help Desk staff members might have Category 2 privileges for all lists
on the server, while a sub-postmaster in a given college or department
would have Category 2  privileges only for the lists associated with
that college or department.

Our central Help Desk is the clearing point for all account suspension
requests, and many tasks associated with account suspension are performed
by Help Desk staff. If administrative privileges could be delegated in the
manner that I have described, central Help Desk staff would be granted
Category 3 (user management) privileges.

We have attempted to provide Category 2 privileges to selected support staff
by creating special lists to which those staff members are subscribed, then
configuring new lists to grant ownership privileges to subscribers on the
special lists. However, there is no way to prevent a list owner from removing
the special 'Owner=' statement from a list. In addition, we have hundreds of
lists which were created before we implemented this scheme, and each of these
must be updated manually by the postmaster to add the special 'Owner='
statement.

This message is not intended to be an enhancement request (except maybe
the part about using individual passwords on 'serve' and 'pwc'). Rather,
it is submitted as fodder for discussion regarding future development.

LISTSERV currently meets our needs better than any other mailing list
management product available today, but there are several areas in which
the product could use improvement. This is one of them.

--
Paul Russell
Senior Systems Administrator
OIT Messaging Services Team
University of Notre Dame

ATOM RSS1 RSS2