secondary group for the user

[Amit Phadnis]

Hi,

Is there any secondary group funda in the Open VMS? If there how to create the secondary group for the user?

Actually I want to make create a .com file, which after executing will allow only limited and particular defined users only to login.

Rest all other users will not able to login.

Also if any user is already logged in, afer running this file,his session should get killed if his username or UID is not mentioned in the group which is allowed.

have U any plans or script for this?

Amit.

[Ian Miller.]

The command procedure could define a logical name. In SYLOGIN you could check for this login and only allow the required users to login. The command procedure could also scan for users currently logged in and log them out (see F$CONTEXT, F$PID, F$GETJPI)

[Robert Gezelter]

Amit,

If I understand the posting correctly, there are really two questions:

1) can I limit logins to a particular group?
2) can I log off users who do not belong to this group?

The answer to both questions is yes, although the techniques are different.

Microsoft's Windows family of systems (Windows NT, 2000, XP, 2003, VISTA) use a concept of accounts belonging to multiple groups as part of their security model. For example, an account may be a member of the Admistrator, Site Administrator, and Remote Users groups). OpenVMS uses a slightly different model.

In OpenVMS, users have a single group assignment. This is used for as part of the privilege and basic file management scheme. Users (and their processes) and also may hold a collection of Identifiers. The meaning of "Holding an Identifier" is most commonly access rights to a set of files and resources, which is part of the overall protection environment.

Identifier possession can also be checked from DCL (using the lexical function F$GETJPI) and the underlying system serice or run time library call from within programs. How to do this is covered briefly in my DECUS presentation "DCL Lexicals: OpenVMS Juhitsu" from the 1995 Fall US DECUS Symposium, available through http://www.rlgsc.com/decus/usf95/index.html

A modification to SYS$MANAGER:SYLOGIN.COM to check for a particular Identifier under certain circumstances is not difficult. Please remember to omit the consequences if the user is a member of one of the system management groups (or holds the SYSPRV) privilege.

Logging people off who are already on is more complex, but can be done.

I hope that I have been of assistance. If I have been unclear, please let me know.

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

[Hein van den Heuvel]

There are scripts floating around to prohibit multiple logins

The best method on VMS for this is to simply $OPEN/ERROR=in_use a specific file exclusively. If that works, the process is the first and only. If it fails, well it is in use and the scipt jumps to label 'in_use' where you issue an expkanation, log the event and exit.

There is no multy group concept, but something close and better on VMS: RIGHTS.
You PROTECT specific OBJECTS (like files) and then allow holders os specific RIGHT to access them A user can have many or no rights.

Please check the manuals (and help) for a while before asking details.
Hints:
$HELP SHOW PROC/RIGHT
$MCR AUTHORIZE HELP GRANT
$MCR AUTHORIZE HELP ADD
$HELP SET SECU
:

hth,
Hein van den Heuvel

[Amit Phadnis]

Heuvel,

As you have mentioned, we can use RIGHT concept to protecting the users from login. But in that case, that will be all time protection.

my requirement is such that, suppose we are having server maintainance and we want no users should login except system administrators. In such case these prevetion of login to others users is for particular short time. After which they again should able to login.

Will this thing can achieved by logic you are suggesting?

Amit.

[Martin Hughes]

The method suggested by Ian is the neatest way to lock out general users. Setting this up requires some DCL skills and familiarity with lexicals.

Another method is to set interactive logins to zero, thereby stopping any users without OPER privelege logging in. This method assumes that your general user base does not have OPER privelege.

[Hein van den Heuvel]

>> As you have mentioned, we can use RIGHT concept to protecting the users from login. But in that case, that will be all time protection.

Well, you could dynamically chance security settings, but that does not feel right.

Admittedly I read your question differently from what you intended and now clarified.

Teh file mechanism was in fact a cheap / simple wrapper aroudn the OpenVMS Lock Manager.

LOCKS, not logical names, are the very best way to control this, but require real programming, not scripting. You can require a concurrent-read lock for 'normal users'. In special times, request a 'protected write' lock. This can trigger a blocking AST in for the normal users allowing for very gracefull end (message to screen). If the user do not go, then GETLKI can be used to find out who is blocking. Cluster wide. Sweet stuff!

Files can be used to approach this:
$OPEN/READ/SHARE=READ/ERROR=closed_for_business for normal use.
$OPEN/READ/ERROR=kill_users for super use.

$SHOW DEV/FILE would give a quick list of PIDs to STOP if neede.


>> my requirement is such that, suppose we are having server maintainance and we want no users should login except system administrators.

Would that be for 1 system, or the cluster?

Anyway, the OPER priv, as replied just now, already implements the prevention of login in. It does not kill. A quick DCL loop with F$GETJPI and checking for processes holding OPER priv should be easy enough to construct.
Be sure to use 'STOP/EXIT' instead of, or before 'STOP/ID' to give processes a chance to clean up. (flush RMS buffers). On older VMS versions you may need a little program (as provided below) to achieve that.

Hein.

#include stdio
main(int argc, char *argv[])
{
int pid, sys$forcex();
if (argc < 2) return 16;
sscanf (argv[1], "%x", &pid);
return sys$forcex(&pid,0,0);
}


>> In such case these prevetion of login to others users is for particular short time. After which they again should able to login.

I might still prefer, and try to get, to blcok specific activities, not the login.
Surely there is no harm just having them logged in. They should just not be able to do certain things which is different all together. Blocking login is too big a hammer for a subtle person like myself :-).

Compare with cellphones in the airplane/theater/meetings. Do you want to prevent the audience from walking in with a phone (at performance times) or do you just want them not to use it during special times?

>> Will this thing can achieved by logic you are suggesting?

Ys, As per shared file explanation.

Regards,
Hein

[Robert Gezelter]

Amit,

Preventing users from logging on during maintenance is straightforward using identifiers.

The (most flexible) way it is done is to define a logical name in the system, group, or other persistent logical name table that specifies what identifiers are PROHIBITED from logging onto the system at this time. Then then embed the appropriate check in the SYS$MANAGER:SYLOGIN.COM file (I have also accomplished similar things using group login files and concealed logical names, as was described in my OpenVMS Technical Journal, article (see http://www.rlgsc.com/publications/vmstechjournal/inheritance.html ).

In this way, "maintenance" can be defined in a far less privileged way, since the Group Logical Name tables are controlled by a different privilege. The same thing can be done with separate logical name tables to control different applications.

The key to this is the list of identifiers held by each user, and locating user default directories on a rooted directory tree pointed to by a concealed logical name (as described in the article).

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

[Jan van den Ende]

Amit,

you specified
>>>
my requirement is such that, suppose we are having server maintainance and we want no users should login except system administrators
<<<

VMS (or OpenVMS, which really are the same) has, from the earliest I can remember, always had a dedicated mechanism for that:
$ SET LOGINS/INTERACTIVE=0

Then only users that have DEFAULT PRIV = OPER (typically system managers & operators, or what you call Administrators) in their authorisation are allowed to log in.

If service is to resume, then simply
$ SET LOGIN/INTER=

hope this helps

Proost.

Have one on me.

jpe

[Jon Pinkley · Accepted solution]

The use of a logical name containing the list of "exceptions" and a check in SYS$SYLOGIN has been proposed, and that will work. I will make an alternative proposal.

The use of identifiers (RIGHTS) can be used here. Specifically, the combination of process and system rights.

First create an identifier that you will grant to users that you want to allow to log onto the system when the others are disallowed. For this example, I will use DB_ACC. This same identifier can be used to grant access to files, or even charge disk quota against if it has the resource attribute.

Now grant this identifier to all the users that you want to be able to log in at all times.

Now the non-obvious part. VMS allows you to grant an identifier to the current node (system). These rights show up in the System rights: list at the bottom of the output from

$ show process/rights

On most systems, the only identifier that will show up here is the node specific identifier, SYS$NODE_nodename. For example, if your nodename is AMIT, you will see SYS$NODE_AMIT.

Let's assume that you normally allow all users to login, but prohibit logins when some special system maintenance is in process.

In your SYS$COMMON:[SYSMGR]SYSTARTUP_VMS.COM issue the command:

$ set rights/enable/system DB_ACC

Once that is active, all processes on that node will "hold" the DB_ACC identifier; i.e. it will show up in the list returned by f$getjpi("","RIGHTSLIST")

After it has been added to the systems rightslist, put a check in your SYS$SYLOGIN to check whether this identifier is in the list of rights.

For example

$ myrights_c = "," + f$getjpi("","RIGHTSLIST") + ","
$ if f$locate(",DB_ACC,",myrights_c) .lt. f$length(myrights_c)
$ then
$ ! allow login
$ else
$ ! disallow login
$ endif

Your command file to disable logins would then have the command:

$ set rights/disable/system DB_ACC

and to re-enable:

$ set rights/enable/system DB_ACC

Note that all UICs that have been explicitly granted the identifier will have DB_ACC in their process rightslist, and therefore taking it out of the system rightslist will not affect them.

You also want to kill all the currently logged in processes that do not hold the DB_ACC identifier, so you will need to have the command procedure scan through all the processes as suggested by Ian Miller, but check if DB_ACC is in their process list, and kill them if it is not. This is similar to the case with logical names.

The advantage of using a logical name with a list of "excluded" users would be that it is much easier to change "on the fly". If you have a cluster, you can even put the logical name in a clusterwide logical name table. If you have a cluster, and you don't need to control access to files based on whether the identifier is held, then this is a lot simpler than using system rights, which must be enabled on each system in the cluster.

The advantage of identifiers is that they can be used to protect access to various objects, like files and queues.

We use the identifier method, and sysman to enable/disable the system rights clusterwide.