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 || ------------------------------------------------------------------------------ ------