The user classes, e.g., *USER and *SYSOPR, have practically nothing to do with the authority for those commands. They mostly have nothing to do with authority for any commands at all.
They do have some purposes though.
First, when CRTUSRPRF is run, the USRCLS() parameter value is used by the command itself to assign a set of "special authorities" for the SPCAUT() parameter. You may accept the default set or change them in any way that you are authorized to do.
Next, for system menus and system UIM panels, the USRCLS() setting is used to determine which menu options are made available or which panel elements will be displayed. If a *USER user profile goes to the MAIN system menu, some of the options will be missing. If a *SYSOPR user goes to the MAIN menu, more of the menu options will be shown.
In any case, for nearly all commands at <i>most sites</i>, it will be the *PUBLIC authority that has greatest effect. Primary exceptions will be users who have a SPCAUT() value that includes *ALLOBJ. Secondary exceptions will be users who have been granted private authority to the commands. In both primary and secondary, those can be for either the user profiles themselves or for any group profiles assigned to the user profiles.
If a user can obtain *ALLOBJ special authority, all bets are off. No *USER nor *SYSOPR user class profile should have *ALLOBJ special authority.
Without knowing the special authorities that are assigned to the particular users who you are trying to control, there's no way for us to tell you how to control them.
Tom
The objects STRPDM and STRDFU can be attached to an Authorisation List. And only required programmer ids can be given access to this Authorisation List. This will prevent other users from accessing the commands.
STRPDM and STRDFU can be attached to an Authorisation List
Yes, they can. But it’s not likely that it will make a difference in this case. Since *PUBLIC *EXCLUDE didn’t solve the problem, the authority is coming from somewhere else. If it comes from *ALLOBJ, it will override the authorization list. (That’s why it’s a “specail” authority.)
Further, restricting STRPDM and STRDFU won’t stop access to PDM nor to DFU. It only stops the use of those commands to enter those products. E.g., restricting STRDFU has no effect on using UPDDTA. There are many ways of using both of those products. It can be difficult to find every product entrance.
Tom
To answer TomLiotta’s question most of the users are *USER but do have *ALLOBJ special authority. I have 3 users that are *SYSOPR with just enough knowledge to access these products and be dangerous.
Thanks very much to everyone for their help. Please feel free to continue adding any thoughts or help.
…most of the users … do have *ALLOBJ special authority.
Then they have authority to all objects. Practically speaking, there’s nothing that can be done to keep them out of anywhere.
There are types of “obfuscations” that you might do to require them to be clever to get access; but it only takes one slightly knowledgeable user to look up stuff on-line or to discover the path around obstacles that you erect. When one learns, others will be taught.
The problem is that when you start camouflaging paths, the clever users hide their access routes. You don’t know when the obstacle was successfully negotiated around. A precarious false sense of security settles in. It can also become a focus of interest — “The game is on!”
If a user has (or can obtain) *ALLOBJ, then any other authority can be obtained. (Of course, if a user has *ALLOBJ, they don’t really need STRPDM nor STRDFU. Those are conveniences.)
Tom