Operating System - OpenVMS
Showing results for 
Search instead for 
Did you mean: 

Account for login and read privilege


Account for login and read privilege

Because the system account is very dangerous for average operator, so I want to create a account just ownes login,read, can't write,delete and modify files, which privilege is necessary? NETMBX,OPER, is ok? Thanks!
Hein van den Heuvel
Honored Contributor

Re: Account for login and read privilege

For my work I tend not to be too converned with privs, so this is not going to be the best answer for you, just a start.

Be sure to carefully check Table 2 "OpenVMS Privileges" in the OpenVMS security manual.


Pay close attention to the 'categories' :
normal, group, devour, system, objects, all.

Seems to me you want to avoid 'all' but may tolerate as much as 'objects'.

I kinda like 'readall', I hate 'bypass'.
I do NOT want BYPASS in any default priv mask. SYSPRV is almost as dangerous, but useful. Be careful with the UIC group you assign for the average accounts.
Pick it ABOVE the SYSGEN value for MAXSYSGROUP, to prevent exessive object privs.

Read a lot, go carefully!

Good luck!

Robert Gezelter
Honored Contributor

Re: Account for login and read privilege


I concur with Hein. A careful read of the Guide to System Security is in order.

However, some notes, many of which appeared in my presentation "OpenVMS User Environments" (notes at http://www.rlgsc.com/hpworld/2004/N227.html ), where I discussed managing large environments without corresponding numbers of privileged users.

In particular, one wants to look at using the ownership of different queues and devices to allow otherwise non-privileged users to do operator level tasks. Just because a user/operator is authorized to reset the print queue for finance does not mean that they should automatically have the authorization to work with another group's printer.

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

Re: Account for login and read privilege

And if the operations staff has specific and more privileged tasks that need be performed in response to various stimuli, consider setting up a DCL menu and a CAPTIVE environment, and generally keeping an operator away from the $ prompt when the ALL-class privileges are lit.

There can and will be exceptional cases, when DCL access is required, and with full privilege bits lit. But the run-of-the-mill stuff is where the usual "oops" problems creep in.

And yes, do check the manuals and do check your tasks for which privileges are required.

I had included examples and information on CAPTIVE and security-related tasks in the 2nd Ed. of the Writing Real Programs in DCL book, if you can find a copy of it. The book is reportedly out of print.

Stephen Hoffman
HoffmanLabs LLC
Regular Advisor

Re: Account for login and read privilege

You probably want to setup some kind of menu system and provide the operators with specific commands or programs they can execute by picking a menu choice. If you need to provide them with DCL command line access, you can modify their DCL tables to eliminate such commands as DELETE, OPEN, COPY, EDIT, etc. That would leave them with TYPE, SHOW, etc. There are a lot of DCL commands, so you might want to look at the DCL Commands Reference and determine which commands you want them to be able to use.

You can also set file owerships and file protections to allow particular operators access to certain files. E.g., $ set file/prot=(w:r) and set file/own=. This would require setting up the file ownerships in the AUTHORIZE utility.

So there are a number of options including making the account CAPTIVE, disabling CTRL-C and CTRL-Y so they can't break out of the menu system and so forth.

You might want to come up with a set of requirements so you can determine what approach to take and what all you want certain operators to be able to do and be responsible for. You might have to hire somebody who can do all of this type of work for you if you can't do it or don't have anybody on your staff that can do it.
Hakan Zanderau ( Anders
Trusted Contributor

Re: Account for login and read privilege

Let's look at your problem from another angle.

An Operator is still an operator, not a user.

Wouldn't it be better to trust the operators and send them to OpenVMS training instead of putting effort and $$ on restricting their accounts ?

Don't make it worse by guessing.........