[comp.os.vms] Summary: Creating usernames on the fly

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

------