hamm@BIOVAX.RUTGERS.EDU (04/19/87)
[Long message]
Many weeks back I posted a query about how people used the SYS$SYLOGIN
logical name and the LGICMD qualifier in AUTHORIZE in conjunction with
users' LOGIN.COM files. I received quite a few interesting replies (for
which many thanks!), which I will try to summarize here.
First, though, this exercise revealed two erroneous (or at least misleading)
points in the VMS documentation (System Manager's Reference Manual v4.4,
page 5-7):
1) Under the heading "User-specified command file", it says "If
individual [i.e. LGICMD] or system [i.e. SYS$SYLOGIN] login command
procedures are not implemented, the system looks for a command file
called LOGIN in the user's login directory....The file name must
be LOGIN."
Aside from the fact that everyone I know calls such a file LOGIN.COM
instead of LOGIN., the condition is incorrectly stated. A user's
LOGIN.COM is executed even if SYS$SYLOGIN is defined (in which case
the file defined by SYS$SYLOGIN is executed first, and the user's
LOGIN.COM second). On the other hand, defining the LGICMD qualifier
within AUTHORIZE does indeed turn off automatic execution of the user's
LOGIN.COM.
One result of this is that if you want to have the system-wide login
command file invoke the user's, you probably don't want to use the
SYS$SYLOGIN mechanism to invoke the system-wide file: the user's
LOGIN.COM will be executed twice if you do. Also note that if you
invoke the user's file explicity from SYLOGIN, it will be executed
*before* any file you specify with LGICMD.
2) Although the same page tells you to define SYS$SYLOGIN if you want
to set up a system-wide login command file, it fails to tell you
you need to do this in EXECUTIVE mode, i.e.:
$ DEFINE/SYS SYS$SYLOGIN X.COM ! doesn't work
$ DEFINE/SYS/EXEC SYS$SYLOGIN X.COM ! does work
OK, now the promised summary. Since most of the replies were posted, I've
not included names and message headers to keep this from getting even longer.
My original question was:
> I've come across two ways of handling login command files, and wonder whether
> anyone knows a reason to prefer (or abhor) one or the other:
>
> 1. SYS$SYLOGIN is defined to point to a system-wide login command
> procedure, which is thus invoked for all processes. LGICMD (in the
> UAF) for each user is defined to point to the file LOGIN.COM in
> that user's home directory.
>
> 2. SYS$SYLOGIN is undefined, but LGICMD for *all* users points to
> the system-wide login command procedure. A line late in this command
> procedure checks to see if a user LOGIN.COM exists, and, if so,
> executes it.
>
> As far as I can tell, these two methods are superficially equivalent. Each
> results in both levels of command procedure being executed in the proper
> order, and neither chokes if no user LOGIN.COM is present.
The first point that nearly everyone made was that the two methods are *not*
equivalent; the LGICMD method can be circumvented if a user logs in with
the /COMMAND=x or /NOCOMMAND qualifier, whereas the SYS$SYLOGIN cannot be.
(However, the action defined by LGICMD *can* be forced on the user if the
account is defined with the CAPTIVE flag set, and in fact this is apparently
the preferred method for defining such an account.)
The majority seemed to be for method (1), where SYS$SYLOGIN is defined and
the user's file is *not* invoked by the system-wide file. Many people also
pointed out that this method needn't include the definition of LGICMD, since
the user's LOGIN.COM will be invoked by LOGINOUT in any event. (This was
the point I had missed due to the documentation problem noted above.)
But there were fans of the second method (using LGICMD to point at the
system-wide command file, which in turn invokes the user's LOGIN.COM):
...It is possible to give some users a special login command file...
...We have a command file called "staff_only" that restricts login
to staff members. This command file gets activated by defining
SYS$SYLOGIN...
[N.B. if you do use LGICMD to invoke your system file, it **must** invoke
any user's files, which will not otherwise be executed.]
With either method of invoking a system-wide command file, some people felt
that letting this file invoke the user's explicitly had advantages, to wit:
...the system wide login can run the user's login with
Set NoVerify for, say, batch jobs. That way each user doesn't have
to see his login at the top of his batch file logs even if he doesn't
know how to (or want to bother) with getting the Verify parameter
right himself...
...I had a problem with students copying trojan login.com's into other
users' accounts....I use SYLOGIN to look for the login.com on the
user's account. SYLOGIN checks the UIC of the login.com. If it is
the same as the user logging it SYLOGIN goes ahead and runs it. If
it is not the same, SYLOGIN sends the file to me through mail, does
not run it, and deletes it.
Some people also had very creative schemes for controlling access to various
networked or clustered machines using combinations of SYS$SYLOGIN and
LGICMD.
In the end, I decided to use SYS$SYLOGIN to invoke a system file, and to
use LGICMD (unnecessarily) to point to the user's LOGIN.COM. Somehow, I like
to see it explicity sitting there in AUTHORIZE (security blanket programming).
I also use LGICMD to define "turnkey" accounts, with the CAPTIVE flag when I
want to make it stick.
Thanks to everyone who replied.
Greg Hamm
Rutgers Molecular Biology Computing Lab
hamm@biovax.bitnet
hamm@biovax.rutgers.edu8
Pa
Disni