[Info-vax] prevent user login during and after startup

[David Froble]

Stephen Hoffman wrote:
> On 2014-09-17 17:55:35 +0000, bdhobbs18 at acm.org said:
> 
>> OP responding to some of the replies.
>>
>> Abrsvc mentioned modifying sylogin.com and using "set log/int=0".  I'm 
>> kind of leaning toward this, but that's going to involve more code, 
>> testing, reboots ... sigh.  Hmm, there doesn't appear to be a lexical 
>> for login limit.
> 
> f$getsyi("IJOBLIM")
> 
> Also see the startup login symbol startup$interactive_logins in the VMS 
> docs.  That is how you have the startup not enable access.
> 
> Definitely check ssh, as at one point that did not honor SET 
> LOGIN/INTERACTIVE=0
> 
>>  I guess I'll have to parse the "set log" output.
> 
> I know it's a stretch here, but Google is a very good resource — until 
> VSI gets their business in gear, pretty much every VMS question ever 
> asked has been answered.
> 
>> Bob Gezelter and David Froble mentioned the TCPIP command procedures.  
>> "Toto, I've a feeling we're not in Kansas anymore."  The UCX command 
>> procedures appear to be very different from the later TCPIP command 
>> procedures and not as clear.  Heck, I had to edit one of them because 
>> it had the wrong count for a list of services.  The start of the 
>> telnet service is buried in with the other services, not an 
>> independent startup command procedure.
> 
> Fossil versions have fossil problems and fossil doc.
> 
> TCP/IP Services V5.0 and later uses the TCPIP$ prefix.  Prior to that 
> used the UCX prefix.
> 
>> VAXman mentioned the system should boot without me having "to perform 
>> any manual system schtuff".  That's what I'm trying to get to, but 
>> those pesky users want to use the system NOW!
> 
> Get rid of OPER privilege.  This is far from the first time somebody has 
> tried to implement privileges for privileges.  That's what you're doing, 
> after all — privileges for privileges.
> 
> Get rid of OPER, and this particular problem goes away.  Possibly some 
> other problems, too, depending on what else OPER is being (mis)used for.
> 
> Possibly slightly more politic: announce that those folks with 
> privileged usernames including OPER are responsible for maintaining and 
> monitoring the system integrity, particularly given their exalted 
> privileged stature.    They're privileged users, and expectations are 
> higher.  If they screw up and log in when logins are disabled, yank OPER 
> privilege.  If you're really feeling charitable, put a message to this 
> effect in SYLOGIN.COM.
> 
> 
>>  My predecessors made some significant (and, I think, peculiar) 
>> changes to the system.  For instance, there is no sys$batch queue, 
>> though there is a system$batch queue.  The CLI tables file has been 
>> butchered, that took me a while to figure out why some of my DCL was 
>> not working as expected.  It's a mess.
> 
> Usual path out is a reinstallation and a migration to a saner environment.
> 
>> VAXman and Stephen Hoffman mentioned an alternate sysuaf.dat.  
>> Occasionally I escape work and I have to explain to the poor sap 
>> taking my place what to do.  I think a modified sylogin.com and 
>> explaining "set log/int=0" would be easier than explaining an 
>> alternate sysuaf.dat and extra reboots.
> 
> I do think that addressing the actual problem and not continuing to 
> dance around it — get rid of OPER privilege — is far more direct?
> 
>> Jim Carpenter mentioned that the CHARON-VAX emulator can use the 
>> host's clock.  I believe our version (3.1, 2005 Aug 22) does not have 
>> that option, but I'll check that again.
> 
> Fossil versions for the headaches.
> 
> Might want to check and see of CHARON-VAX has a console port 
> capability.   SIMH has that, and that'd give you a path into the server 
> via the (emulated) OPA0: for a look around.
> 
>> Martin Vorländer mentioned "UCX> set configuration enable NOservice 
>> telnet".  My UCX documentation doesn't show this command and I'd be 
>> afraid that the "NOservice" might delete the telnet service if it did 
>> work.
>>
>> VAXman mentioned sysman startup.  I'm not familiar with sysman, but I 
>> poked around a bit, lots of shows.  I didn't find UCX or telnet, I 
>> suspect I may be doing it wrong.
> 
> You're probably invoking UCX$STARTUP in SYSTARTUP_VMS.COM.  You'll not 
> find UCX / TCP/IP startup in SYSMAN.
> 
> 
>> I'm going to try re-doing the telnet service to see if I can get it 
>> disabled at startup.  If that doesn't work, then I'll try the modified 
>> sylogin.com and "set log/int=0" command.  Unless someone posts 
>> something better ...
> 
> Fix the actual problem.  Yank OPER.  Clean up the mess.  Upgrade to more 
> current versions.
> 
> Seriously: if you do not have the support of your management to start to 
> fix this stuff, then you're doomed from the start — you're just 
> continuing the same path that led to what you're seeing, and you're in 
> an untenable position.   Explain what you've discussed here to your 
> boss, and show what the effort will be to allow these folks to continue 
> to have their privileges, versus the effort involved with using the 
> supported mechanisms and with non-privileged users; with TMPMBX and 
> NETMBX and not OPER, or higher privileges.  (OPER, BTW, can be used to 
> cause other system chaos when in the right — wrong? — hands.)
> 

Steve makes good points.

Privileges.  They have specific purposes.  Don't allow misuse of them.

VMS version.  Really, 7.1 is more than a bit dated.  I've run V7.2, it's 
better, and V7.3 was the last VAX release.  Both have been pretty well 
beat up, and should not have many problems.  Quite likely less problems 
than V7.1.  Is there any reason why you cannot upgrade the OS version? 
If not, then you should look at doing so.  Moving to a new version also 
gives you some "weasel room".  Do a fresh install, then modify and / or 
change only what's required.  Tell those with improper privs that it's a 
new version fo the OS, and things will be different.

My opinion.  When VSI gets to the point of licensing, or whatever they 
choose to do, every VMS user owes it to themselves to have a software 
maintenance contract or whatever it might be called with VSI.  It's a 
two way street.  VSI will need the support of VMS users.  VMS users will 
need VSI to keep VMS going.  Doing so I'd think would make VMS versions 
available to the users.

If you want, get me a copy of the UCX$STARTUP.COM and I'll take a quick 
look to see if it's simple to turn off the Telnet startup.

A (SEARCH UCX$STARTUP.COM telnet) might be informative ..