Release 1.5j implements 2 new commands, GETALL and PUTALL, which allow the
postmaster or any filelist-owner to override the GET/PUT FAC he specified for
any file under his control. The syntax is exactly the same as GET and PUT, but
it takes more CPU time to execute of course. The algorithm is very simple:
- If you can GET (resp PUT) a file, you can GETALL (PUTALL) it at no
additional CPU cost. Otherwise you enter the following algorithm:
o If you can PUT or PUTALL the filelist which contains the file, you can
PUTALL it.
o If you can PUT or GETALL the filelist which contains the file, you can
GETALL it.
Don't be mislead by the recursive definition: the code that actually
implements it is NOT recursive -- we don't have any CPU/storage to waste, do
we? :-) As implemented it is about 50% slower than a normal PUT for two levels
of nesting (LISTSERV FILELIST <-- CONTROL FILELIST <-- file).
In good english it means that if you can modify the filelist that defines
the file, you can change the appropriate FAC and become an owner of it. Ditto
if you can modify the filelist that defines the filelist that (...). You got
it :-) So instead of doing the GET/PUT on the filelist, then GET/PUT on the
target file and another GET/PUT on the filelist to set things back straight,
LISTSERV allows you to do a GETALL or a PUTALL directly if you really (badly)
need to GET/PUT the file. For example, if a new LISTSERV is installed and has
an obsolete version of BITEARN VERSION in its CONTROL FILELIST, I could issue
a PUTALL command to update the file without having to bother Bert with it
because CONTROL FILELIST is PUT=LMC (will be -- with 1.5i all filelists are
PUT=N/A because you just could not PUT them :-) ). Another application is that
the postmaster can now issue a PUTALL command on PEERS NAMES and enjoy the
automatic table refreshing (because LISTSERV FILELIST is PUT=CTL), instead of
doing a PUTC and then having to issue a few CMS commands to rebuild the
tables. :-)
Important note: under no condition of privilege or ownership can you
override a FAC of N/A. N/A means just what it means, NOT APPLICABLE. When I
set a file to PUT=N/A, it generally means that executing a PUT command on it
might have very nasty adverse effects and it should not be allowed. Example:
the entry is for a file that does not really exist but is under control of a
File Access Validation exit which generates a caller-dependent file when
called for a GET command (that's a possible LISTSERV implementation of
NETSERV's "GET NODENTRY nodeid" command). The file is mapped to some fileid
because there must always exist a fileid for each file (even if it's just a
place holder), but it must NEVER be PUT, under NO condition.
An important drawback is that if you have a File Access Validation exit on
one of your filelists (eg LISTSERV FILELIST) and decided for some reason to
set the PUT FAC to ALL because the FAV exec does all the userid@node
validation, you are allowing anybody to GETALL/PUTALL anything. This is not a
security problem since release 1.5j forces a built-in FAV to be called when a
PUT takes place on a filelist (to check the contents of the filelist) -- the
original FAV, if any, is ignored. It is just a permanent restriction of
LISTSERV -- filelists cannot have their FAV called during the PUT command
processing.
I have also revised the PUT command password scheme. The algorithm is now
different:
- If you have a personal password (from PW ADD), then this password is
accepted for ANY PUT/PUTALL command coming from you.
- If you do have a personal password but opt to use the filelist-defined one
(or, when applicable, the list password), it's ok too. You choose the
password you want.
- If you don't have a personal password, you MUST use the filelist-defined
one.
This means that you can use your personal password for all your local PUT
commands, and you don't have to resort to the filelist one unless your PUT
command is going to be distributed to servers where you don't have a password,
or where your password is different. It gives you more freedom while still
allowing you to PUT NODIST a file on any server if there is a problem with it,
even if you don't have a password on that server.
Finally, there is a new keyword to the PUT command: CKDATE=YES (requires
DATE= to be specified). This cause the server to compare the date of the new
file (from DATE=) with that of the old file, and reject the PUT if you're
sending an older file. In other words, if you're putting one file today and
again tomorrow while the file queues had prevented the first one from going
through, you can be sure that the old one will not overwrite the latest one
just because it was smaller :-)
Eric
|
