startup$interactive_logins

[John Koska]

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?

[Uwe Zessin · Accepted solution]

There was some discussion which might help:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=501651

[John Koska]

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]

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

[John Koska]

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]

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

[Wim Van den Wyngaert]

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

[Antoniov.]

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

[Galen Tackett]

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]

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]

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