hamm@BIOVAX.RUTGERS.EDU (07/25/87)
A few weeks ago, I posted a query about how to magically convert a 'generic'
login to a newly created username on the fly. This was intended to support
a dial-in bulletin-board service for which I wanted to register users
on line, rather than dealing with lots of paperwork. The idea was to allow
people to dial in, log into a general account, run through a registering
dialog, and - zap - they'd be logged in to their shiny new account.
For this purpose, I had intended to modify a utility (BECOME, I believe now
available on one of the DECUS tapes?) which was written several years ago by
Roy Omond <OMOND@EMBL.BITNET> at my old lab to allow systems staff to "become"
other users for file repair and similar work. What I thought I wanted to know
was what additional things would need to be zapped, since VMS has changed (!)
since then.
Several people replied to me, and several to the net; I thought it might
be useful to summarize their comments in one place, and in particular to
repeat Jerry Leichter's <leichter-jerry@yale-venus.ARPA> elegant solution
which I will use. Thanks again to all who replied.
1. First of all, several people warned me of the dangers of kernel mode
programming. I certainly agree with this warning; I remember the crashes
when BECOME was under development. I had hoped that only minor modifica-
tions might be necessary, and that the crashes might therefore be kept to
a minimum.
2. Secondly, some notes on additions to BECOME which would have been
necessary:
...You would have to change Become slightly to zap in the true username
into the PCB and JIB, something it doesn't do now in order to allow one
to Become oneself again ! But in this case, that's not necessary.
Should all be possible and not really all that difficult....One more
thing is that the job logical name table would have to be set
read/writable (ACL ?)
3. A couple of people sent other programs which will change the username on
the fly. (Note that such programs should be installed with CMKRNL - the
captive process should *never* be given such privilege, as some people
thought I wanted to do.)
4. One very important point which I had completely overlooked was raised by
John Hanley <hanley@cmcl2.NYU.EDU>, and in fact applies to Jerry's
solution as well:
I suggest you keep track of some sort of moving average of the rate at
which this wide-open account creates what you call "brand new shiny
accounts." It seems to me this is comparable to essentially giving
J. Random Luser "devour" privileges. Since there are very few sites that
permit malicious types to add as many entries to SYSUAF.DAT as they like,
it's possible that you might even uncover the occasional heretofore
undetected bug. In short, I recommend that you refuse to create shiny
new accounts if more than, say 5 or 8 have been created in the last 10
minutes, and also if more than 20 or so have been created in the last 3
hours. Any time more than about 10 accounts are created within an hour
a mail message noting that fact should be sent to whoever administers the
beast.
5. And finally, Jerry's solution, which is both elegant and much easier
to implement than any fancy kernel-mode footwork:
Mr. Hamm then asks about ways to patch the job so that it appears to
be running under some other account.
Doing this is not easy. There are several account-related fields, and
you'd have to be sure to patch all of them. The result would be highly
likely to break with new versions of VMS.
There's a much easier solution, that isn't based on anything unsupported:
Once you've created the new account, tell the user, "OK, the way you'll
log in from now on is .... Now we'll try it out:" Then do:
$ assign/user SYS$COMMAND SYS$INPUT
$ set host 0
$ <whatever>
Yes, the new user has to log in again - once, when he registers. The
ruse of "trying it out", however, will keep anyone from complaining
about it - in fact, most people will probably appreciate the opportunity
to see ahead of time what they should expect. Further, at <whatever>
you can ask the new user if all went well with the session, and if not
give him help until he IS successful in logging in - rather than leave
him scratching his head the next time he tries out his new account and
finds that he got the password recorded wrong, or whatever.
This accomplishes everything I wanted to, and is in fact much better from
the standpoint of dealing with very naive users than my intended solution
--however well implemented--could ever have been.
Greg
------------------------------------------------------------------------------
Greg H. Hamm || Phone: (201)932-4864
Director, Molecular Biology Computing Lab ||
Waksman Institute/NJ CABM || BITNET: hamm@biovax
P.O. Box 759, Rutgers University || ARPA: hamm@biovax.rutgers.edu
Piscataway, NJ 08854 * USA ||
------------------------------------------------------------------------------
------