Allow selective LOGIN when interactive is set to 0

[ChaimBu]

We have circumstances where we only wish to allow a selective group of programmers to be able to LOGIN to the system. This group can change from circumstance to circumstance.

Currently the operators set the login interactive count to 0, and then open/reclose upon specific request. The problem with this method is that during the short period during which the interactive count is set to more than 0 other users could by coincidence also login. Giving ALL the programmers the minimum privelege to allow them the ability to LOGIN even when the interactive count is set to 0, is NOT an option.

Does anyone have a suggestion how to "resolve" this issue in an elegant manner?

BTW, what is the minimum privelege that a user requires to be able to LOGIN even when interactive logins is set to 0?

Thanks,

Chaim

[Heinz W Genhart]

Hi Chaim

the minimum privillege to login under this circumstance is OPER privillege.

Another possibility would be not to control login with SET LOGIN/INTERACTIVE, but to control access with a procedure, which restricts login to specified users, controled by the system manager.

Regards

Heinz

[Wim Van den Wyngaert]

You will have to do some programming in sylogin and leave the limit at a high value.

Wim

[ChaimBu]

Thanks for your replies!

Based on these replies, I take it that there is no elegant solution to this problem.

I think I will suggest writing a simple command procedure that will accept a file containing a list of user names and give an optio to either grant or revole the OPER privelege from the users contained in the list. This would then give the desired users the OPER for the duration of the task and then the system manager could rerun the CP to revoke said priv after the task has been completed.

Thanks,

Chaim

[Ian Miller.]

I would check for the presence of an identifier in SYLOGIN which allows logins during the restricted period. Then grant/revoke the identifier as needed.

[Wim Van den Wyngaert · Accepted solution]

Use enclosure in sylogin.com and let the interactive limit high.

Then create a file sys$common:[sysexe]restrict_logins.closed with all users allowed to login surrounded by |.

When you need to close the system (except for these men), rename it to .dat. When you want to close the system for all users, use the interactive limit. To open the system again, rename to .closed.

Wim

[Robert Gezelter]

Chaim,

The SET LOGIN/INTERACTIVE=n mechanism will not achieve what you want. There is, however, a way to accomplish this in a reasonably elegant fashion.

Create a collection of a Identifiers associated with each of the groups of programmers (If the programmers are broken into different groups, then the Group name can be used as part of the Identifier name).

In SYS$MANAGER:SYLOGIN.COM, check the identifiers against a logical name (in Executive Mode, and in a System Owned Logical name table). If the logical name is set correctly, then allow the login. If not, logout the process.

To be certain, ensure that the SYLOGIN.COM file executes with Control-C and Control-Y disabled.

Alternatively, you can accomplish this using a Executive mode logical name in the group logical name table (LNM$GROUP). This table is different for every UIC group.

I hope that the above is helpful.

- Bob Gezelter, http://www.rlgsc.com

[Jim_McKinney]

>>> in an elegant manner?


You may want to investigate the SYSGEN parameter LGI_CALLOUTS and the associated LOGINOUT API (callout_chkrestrict is the vector of interest) to customize the login process. I once used it for just this purpose - to recognize and permit interactive access to a system for select users when IJOBLIM was set to 0.

[Jess Goodman]

There is a safe way to use the OPER privlege to control this. First in the sylogin that these users execute add the line:

$ SET PROCESS/PRIVILEGES=NOOPER

I'm assuming these users' accounts are set RESTRICTED (must execute their login .com) and that they don't have access to edit it.

Then when you wish to allow a user to login modify their SYSUAF account to add OPER to their default privilege list, but do NOT add it to their authorized privilege list.

They will have OPER priv only while their login takes place and will not be able to enable it again.

$ SET PROCESS/PRIV=OPER
%SYSTEM-W-NOTALLPRIV, not all requested privileges authorized
$ WRITE SYS$OUTPUT F$PRIV("OPER")
FALSE

Another possible approach is to use loginout callouts. You can write routines that LOGINOUT.EXE calls to turn OPER on before authentication and turn it back off after authentication based on a list of currently valid users it obtains from a file or system logical name.

[Jeroen Hartgers_3]

If you authorize accounts with a special identifier (example: systemmanager) and you create a system logical like system_closed.
You check this logical for a value if the user has not the ident systemmanager. On this way jou can show a message ik the system is closed for normal use and disconnect the user.