HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Hours:
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

startup$interactive_logins

 
SOLVED
Go to solution
John Koska
Advisor

startup$interactive_logins

It appears there is a window of opportunity for end-users to log on to a system that is either near the end of a reboot or has just rebooted, eventhough startup$interactive_logins , may be set as a global symbol to 0 (ie: $startup$interactive_logins == 0 ) within systartup_vms.com.

The window of opportunity looks like it may be from VMS$BASEENVIRON-050_VMS.COM having startup$interactive_logins set to 64.

Is it safe to set startup$interactive_logins in VMS$BASEENVIRON-050_VMS.COM to 0 to prevent interactive logins by non-privleged end-users?

Any harm to operating system, as in something will not start during reboot?

Perhaps startup$interactive_logins should be set someplace other than at the beginning of systartup_vms.com (before DECnet, LAT, and TCP/IP startups) to prevent window of opportunity to interactively login by non-operator?
10 REPLIES
Uwe Zessin
Honored Contributor
Solution

Re: startup$interactive_logins

John Koska
Advisor

Re: startup$interactive_logins

Uwe,

First, thank me for your repsonse.

If I read correctly from your post as to the suggested reading, one would need to both set startup$interactive_logins to 0 globally early on in systartup_vms.com and also to do set login/inter=0 for job controller to be updated; such that only privileged operators could login after/during a reboot.

I think I will avoid changing VMS$BASEENVIRON-050.COM , since it will get overwritten in system upgrades most likely and/or may have other unknown consequeces.

I've tested as best as one person can, but it is difficult to reproduce 300 to 400 end-users trying to get in during a reboot, where it appears some are lucky and others not pending on when they tried during the reboot.

Having $startup$interactive_logins == 0 and
$set login/inter=0 near beginning of systartup_vms.com does appear limit access to only privileged users being able to login interactively.

I think was missing the part about having to $set login/inter=0 to update the job controller, which was allowing the unprivileged end-users to login interactively.

Thank you again for your reply.

:) jck
Jan van den Ende
Honored Contributor

Re: startup$interactive_logins

John,

in modern times those things may be better then they used to be.
In the time of directly-attached terminals your concerns may have had practical as well as theoretical value, but do you really still have them nowadays?
As longs as DECnet has not started (still running at most sites, I guess), SET HOST to the system is not available (and most probably very rare anyway). As long as the LAT LATCP node has not been started (not relevant anymore at many sites), LTA sessions will not get in. And as long as TELNET is not started, telnet sessions will not be possible.
So, in today's world there is little concern anymore.


Jan
Don't rust yours pelled jacker to fine doll missed aches.
John Koska
Advisor

Re: startup$interactive_logins

Jan,

I did not provide all the relative info on the why's of my question and the direction.

I needed a way to allow operators to login after the rare system crash (who are at many locations with varying usernames), but not the end-users.

With startup$interactive_logins == 0 and set login/inter=0 in early of systartup_vms.com, the operators/privileged are able to get in, but not others.

We have the need for the operators to get in and "fix" the application data before letting the end-users continue to add data to the application. Otherwise, more work in undoing the end-users work, before proceeding.

Now, instead of coding to check who is coming in and from where; and possibly copying sylogin template file in to allow general access, I just tell the operators to $set login/inter=1200 when they are done with their "fixes" after a crash; or any other system shutdown.

Hope that makes more sense now.

The flexibility of OpenVMS is a tribute to those who built it, and continue to expand it.

:) jck
Paul Jerrom
Valued Contributor

Re: startup$interactive_logins

Hi John,
The way I control it in my setup is with the use of logical names specific to each application. When I do maintenance on one application I set the relevant application logical to UNAVAILABLE - ie
$ define/system LAB$STATUS UNAVAILABLE
SYLOGIN checks the relevant application logical (applications have their own UIC groups, your check might be more involved) and either grants or denies access. I have created superuser accounts for each application that bypass this check, so I can login and do maintenance on the application.
During application maintenance I can deny access to one or more specific apps without denying access to the entire server.
I also create a file LAB$STATUS, such that on a reboot the status can be determined.
So your startup procedure might always set the logical to unavailable, until your operators have done their check, at which point they can set the logical to available and let the hungry hordes in.
All the best,
PJ
Have fun,

Peejay
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If it can't be done with a VT220, who needs it?
Wim Van den Wyngaert
Honored Contributor

Re: startup$interactive_logins

Don't forget batch jobs. You need to block them from starting until the application is running.

Best is to start the queue after the startup of the application.

Be carefull with autostart queues. You need to stop them before the enable autostart command.

Wim
Wim
Antoniov.
Honored Contributor

Re: startup$interactive_logins

John,
I use a solution like Paul.
Boot of end-user application define a system logical that means application lives.
In SYLOGIN.COM I check if logical name is active so only privilegiated user can login.
Shutdown of end-user application obviously remove system logical name.

Antonio Vigliotti
Antonio Maria Vigliotti
Galen Tackett
Valued Contributor

Re: startup$interactive_logins

To prevent interactive logins could you set IJOBLIM to 0 either via MODPARAMS.DAT and AUTOGEN up to SETPARAMS(the preferred method) or via the quick and not-so-dirty:

$ RUN SYS$SYSTEM:SYSMAN
SYSMAN>USE CURRENT
SYSMAN>SET IJOBLIM 0
SYSMAN>WRITE CURRENT

I believe that when you reboot, interactive logins will be disabled until you specifically enable them. Quoting from the V7.3-2 System Management Utilities manual:

"IJOBLIM sets the maximum number of interactive jobs that can be on the system concurrently. You can control the maximum number of concurrent interactive users on the system with the DCL command SET LOGINS/INTERACTIVE."
John Koska
Advisor

Re: startup$interactive_logins

Thank you all for your replies. I will take them all under advisement.

I believe my question has been answered.

Thank you all again.

:) jck
John Koska
Advisor

Re: startup$interactive_logins

Having given it some thought, for my environment (single application, multiple locations and usernames for operators) and desire to lock out interactive non-privileged end-users on reboot and/or a crash with auto restart; we have decided setting the symbol startup$interactive_logins globally to zero along with a set login/inter to zero early on in the systartup_vms.com to be the way to go.

Thanks again everyone for their input.

:) jck