secondary group for the user

[Jan van den Ende]

Amit,

I would tend to elect Jon Pinkley's method over my own!!

And so mostly, because _HIS_ method also works for NON_interactive accesses..

I worked it over twice, and found it so good, that I intend to implement it on OUR site (of course, after trying it on our sandbox)

I was not aware of
$ set rights/enable/system
so, give Jon full points, and any you did not intend upon may be considered given by me.

Proost.

Have one on me.

jpe

[Robert Gezelter]

Jon,

Enabling and disabling is an interesting solution.

I admit that I prefer using the logical name approach for two reasons:

- it can be controlled it on a cluster-wide basis if desired; and
- it can be controlled on a group-by-group basis (on some systems, I actually have implemented it to leave users on, just remove certain menu items during application maintenance)

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

[Hein van den Heuvel]

Yeah, but you can not see who looked at a logical name. You'll still need a mechanism (rights? privs?) to find out who to kill or suspend.

A shared file is trival and gives a simple method to see who is blocking

A lock gives that also, and can trigger action in consumers, but requires coding.

[Robert Gezelter]

Hein,

Actually, the way I do it it is straightforward. First, I use the logical name to only contain a list of disabled (or enabled) user groups/applications.

Then, if you want to track who attempted to login (and you want the audit events), simply create a file that is checked (if you disable logins for that group, simply protect the file and you will get an alarm).

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

[Jan van den Ende]

Bob,

yes, that is about the thing we use, but with finer granularity:
Each application requires an identifier to activate, and we rename the identifier if we want to block that applic.
The numeric value stays, and the user still holds it, but the Alphabetic check fails, disallowing activation (a lot better/faster/easier than re-granting ~3 - 4 K of users!)
The nodes that the app is allowed to run on is controlled by its DNS name pointing to the allowed nodes, and we catch any tricksters by system-wide LNMs to block access for those that somehow DO try to start the an app at a (temporarily?) forbidden node. Just fantastic for applic rolling upgrades!

But still I LOVE the simplicity of system identifiers, and that mechanism escaped me until now.

fwiw

Proost.

Have one on me.

jpe

[Jon Pinkley]

Jan van den Ende wrote:
>>I would tend to elect Jon Pinkley's method over my own!!

>>And so mostly, because _HIS_ method also works for NON_interactive accesses..

>>I worked it over twice, and found it so good, that I intend to implement it on OUR site (of course, after trying it on our sandbox)

Jan, thanks for the kind words, but I am not sure how system identifiers alone solve the problem of non interactive access any better than the logical name approach, or even the set login/inter=0 approach. We can put ACL's on queues, but that will just cause a submit to fail, and that may or may not be what you want to happen. For interactive users, it is probably ok, but do you want a batch job to fail when it tries to resubmit itself?

In the simple case where all users that you want to allow in have OPER as a default privilege, then a stop/queue/next on user accessible queues, and set login/inter=0 + waiting for any running batch jobs to complete
is certainly a lot simpler than using system rights or logical names. For Amit's case that may be sufficient. That's what we used to do, but we now have the requirement to allow different "groups" of users in at different times, and the use of identifiers is the method I used.

Be aware that if you are using the identifier for access checks in an ACL, having the identifier "pulled out from under" the process can cause failures. The effect is immediate and seen by all processes on the system, just like a system logical name. If the identifier is being used for file access checks in an ACL, and the identifier is removed, the next open will fail. Files that are already open are not affected. This can cause problems if you are not aware of what is happening. e.g. a batch process that is partially complete could fail at the next file open.

We have batch queues for each set of users, and the batch queues are stopped before we do our maintenance. If you allow an entry to start, and it exits due to not holding the identifier, the entry is lost. So you need to either stop the queues, or use queue characteristics to prevent jobs from starting.

[Jon Pinkley]

Jan van den Ende wrote:
"Each application requires an identifier to activate, and we rename the identifier if we want to block that applic.
The numeric value stays, and the user still holds it, but the Alphabetic check fails, disallowing activation (a lot better/faster/easier than re-granting ~3 - 4 K of users!)
The nodes that the app is allowed to run on is controlled by its DNS name pointing to the allowed nodes, and we catch any tricksters by system-wide LNMs to block access for those that somehow DO try to start the an app at a (temporarily?) forbidden node. Just fantastic for applic rolling upgrades!"

That's clever. And it avoids the problem of an application failing due to an identifier being removed out from under it, since the ACLs are looking only at the binary values.

Do you have this identifier check in the application (or a sharable image they link agaist)? Do you use the identifier in any ACLs?

Jon

[Amit Phadnis]

Hi Jon,

thanks for your wonderful solution and logic.
But I am facing problem when granting the identifier to the user. I am getting following error,

UAF> grant/identifier LOGIN [600,5]
%UAF-W-NOTIDFMT, ID name parameter does not translate to ID format

How to ge out of this error.

Amit.

[Martin Vorlaender]

Amit,

$ HELP/MESSAGE NOTIDFMT

The identifier name that you specified does not translate to a corresponding value in general identifier format. Identifier name values translate to either general identifier format or UIC format. General identifier names may be 1 through 31 alphanumeric characters and are stored with an integer value in the range of 32,768 to 268,435,455. General identifiers are created by the AUTHORIZE command ADD/IDENTIFIER.

When the AUTHORIZE command GRANT/IDENTIFIER is used, the first identifier specified must be in general identifier format. In other words, a UIC-format identifier cannot be granted to another UIC-format identifier.

Determine why the identifier name is not a general ID. An identifier name and its corresponding value can be displayed with the AUTHORIZE command SHOW/IDENTIFIER. To change the value of an identifier name, use the AUTHORIZE command MODIFY/IDENTIFIER.

cu,
Martin

[Amit Phadnis]

Martin,

I have used the username instead of UIC, but getting same error message.

UAF> grant/identifier LOGIN aphadnis
%UAF-W-NOTIDFMT, ID name parameter does not translate to ID format
UAF>

Now how to translate to ID Format. 'aphadnis' is the id-name.

Amit.