Gilly400   23625 pts.  |   Jul 29 2008  10:25AM GMT

Hi,

I would recommend using a group profile, this will make it much easier to maintain.

Regards,

Martin Gilbert.

SBatSI   370 pts.  |   Jul 29 2008  8:23PM GMT

Thanks for both of the responses; unfortunately, I had already started down the recommended path, but after I applied PUBLIC *EXCLUDE to the object, an unprivileged user could still execute the WRKJOBSCDE command, so I undid my changes and posted my question here. Here is the existing object-authority setup.

Object secured by authorization list . . . . . . . . . . . . *NONE

Object
User Group Authority
*PUBLIC *USE
QSYS *ALL

The QSYS entry does not confer permissions to an unprivileged user, does it? What am I overlooking?

Thanks again…

Gilly400   23625 pts.  |   Jul 30 2008  1:26PM GMT

Hi,

Do your users have *ALLOBJ special authority ?

Regards,

Martin.

SBatSI   370 pts.  |   Jul 30 2008  2:27PM GMT

Martin -

No way… it makes me shudder just to think of that… ;-} Our regular user profiles have no special authorities themselves; they are, however, owned by a group profile that has *JOBCTL and *SAVSYS special authorities.

Thanks again for your consideration.

Steve B

GAC   300 pts.  |   Jul 30 2008  5:38PM GMT

An alternative path is to exclude all users from accessing the object and then make a menu with the specific commands you want the to use. Isolating the command objects (or making copies of them) in an alternative library can make life easier too.

Best regards,

Gerardo.

Mcl   2500 pts.  |   Jul 30 2008  6:10PM GMT

Three other things to look at.. All are on the User Profile.

1. Limit Capabilities. If set to *YES it should prevent the user from using the command line. If set to *NO or *PARTIAL then command line access will be based on authority.

2. Group profiles. If the user is part of a group that has authority to the object, then the user will get authority to the object. (doesn’t seem to be your issue)

3. Initial program for the user. What authority does that have and is the user inheriting authority from that? Use DSPPGM to determine all of that.

Regards
Mike

Gilly400   23625 pts.  |   Jul 31 2008  3:03PM GMT

Hi,

Worked in quite a few places where the users have *ALLOBJ with LMTCPB(*YES) and specific signon menus - lazy way of security management. The group profile having *JOBCTL & *SAVSYS shouldn’t have any effect on the access to the command (unless this is interpreted as job control?).

Might also be worth checking if you have more than one copy of the command on your system, maybe they’re revoked from one copy, but not from the other - and bear in mind the new “proxy” commands…

Regards,

Martin.

SBatSI   370 pts.  |   Jul 31 2008  11:02PM GMT

I have followed up on all the suggestions kindly provided, and it appears that the issue is with the initial program specified for the users; it is owned by a profile with elevated special authorities, and it runs under that profile. The initial program is required by our line-of-business system, so I will need to research changing the owner to a less-privileged profile.

Thanks again to all for your kind assistance.

Regards,

Steve B

TomLiotta   8025 pts.  |   Oct 17 2009  7:08AM GMT

The initial program is required by our line-of-business system, so I will need to research changing the owner to a less-privileged profile.

Although required by your line-of-business system, that shouldn’t translate to “required as an initial program by your line-of-business system”. There should be no reason to require any program as an initial program.

Further, if you have access to the source code, you can simply block adopted authority from passing to the command line by wrapping the command line access in a USEADPAUT(*NO) program. And if you don’t have access to the source, lodge a serious security complaint with the vendor and demand that they fix it.

Tom

Whatis23   4040 pts.  |   Oct 21 2009  11:33PM GMT

Martin, just curious. How did you prevent your users with *ALLOBJ authority from using WRKJOBSCDE?

TomLiotta   8025 pts.  |   Nov 3 2009  11:55PM GMT

…owned by a group profile that has *JOBCTL and *SAVSYS…

A very bad combination. In fact, *SAVSYS by itself is far too dangerous except for the maybe three or four profiles that would ever need to save the entire system.

Tom