On Mon, 30 Jun 1997 00:32:06 -0400 David R Nessl <[log in to unmask]> said:
>We don't have to create special accounting schemes for other Unix
>data-storage servers such as personal email or ftp or web servers, so
>why should we have to charge specially for LISTSERV?
Because there are two fundamental differences between LISTSERV and the
other things you mention:
- If a user removes his mailbox, or edits the contents with emacs and it
no longer works, this is the user's problem and no one else is
impacted. Likewise if a user deletes his home page, who cares? LISTSERV
on the other hand was not designed to allow random external processes
to edit random files at random times. LISTSERV was simply never meant
to interface to a collection of list archive files managed manually by
end users. It is not a supported use of the software. All changes to
the archives must go through LISTSERV so that the indexes can be kept
in synch. You are free to try your approach anyway, but don't expect me
to agree that it is a good one.
- The FTP or web servers do not write files (except through the normal
login process in the case of FTP). With LISTSERV you have a process
that, by definition, has authority to update all files related to all
lists on the system, and you are proposing to allow end users to have
control over where on the file system LISTSERV writes these files. You
are proposing, in other words, to open a security hole to facilitate
accounting. Well, this is your prerogative, but don't expect me to
agree with you.
I will repeat one last time the approach that I am suggesting. Please
explain to me in "DOS for dummies" terms what exactly does not work with
this approach, as I have yet to hear an explanation that makes sense thus
far:
1. Create a directory tree to which users have no access but LISTSERV has
full access. The world access for this directory is zip. The users do
not have the same group as LISTSERV, consequently the users have zilch
access to this directory.
2. Create subdirectories for the various lists and tell LISTSERV to save
the files there. Only the administrator can tamper with this because
only the administrator has write access to the main directory, which
is owned by LISTSERV.
3. Make a little chown script that changes the ownership of the files
within these directories (but not the directories themselves) so that
they are accounted properly.
The users have no access to this setup and cannot tamper with it. You do
not have a security exposure. You have the ownerships set as your disk
accounting program wants them to be. What exactly is not working with
this setup?
>Also, the Unix sysadmins we can find nowadays don't have a clue about
>how to interface to MVS where our central accounting system resides,
I am sorry to hear that, but this is not L-Soft's problem, is it?
Eric
|
