Controlling access to WRKJOBSCDE

415 pts.
Tags:
AS/400 jobs
AS/400 security
WRKJOBSCDE
Our users need command-line access for a number of commands, but I don't want them to have access to the WRKJOBSCDE command. What is the best way to restrict access to a specific command like this? Thanks in advance...
Asked: Last updated:
Related Questions
1

Answer Wiki

Thanks. We'll let you know when a new response is added.

Hi,

If you do a WRKOBJ WRKJOBSCDE you can set the access to the command. Option 2 lets you change the access you want anyone to have or not to have. You can put *PUBLIC *exclude and just set up for certain user access like a Systems Administration ID or a Group profile and then give what access they can have.

================================================================

The only reason to block access to the Job Scheduler is that your users have been granted too much authority. And if they have so much authority that they can affect scheduled jobs that don’t belong to them, then blocking WRKJOBSCDE won’t fix the problem — they can still schedule jobs or interfere with scheduled jobs without using the job scheduler.

The problem is that you are using scheduled jobs that are owned by the wrong users or you have given *JOBCTL special authority to users who are dangerous to your business.

In the case of *JOBCTL, that special authority overrides other authority restrictions that you attempt to put in place to protect jobs — that’s why *JOBCTL exists, to allow “special” users to ignore authority restrictions for jobs.

If they don’t have access to *JOBCTL, then the only jobs they can affect are their own jobs. If you have users who shouldn’t be controlling their own jobs, you shouldn’t be letting them sign on to your system.

Tom

Discuss This Question: 11  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • Gilly400
    Hi, I would recommend using a group profile, this will make it much easier to maintain. Regards, Martin Gilbert.
    23,730 pointsBadges:
    report
  • SBatSI
    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...
    415 pointsBadges:
    report
  • Gilly400
    Hi, Do your users have *ALLOBJ special authority ? Regards, Martin.
    23,730 pointsBadges:
    report
  • SBatSI
    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
    415 pointsBadges:
    report
  • GAC
    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.
    300 pointsBadges:
    report
  • mcl
    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
    2,740 pointsBadges:
    report
  • Gilly400
    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.
    23,730 pointsBadges:
    report
  • SBatSI
    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
    415 pointsBadges:
    report
  • TomLiotta
    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
    125,585 pointsBadges:
    report
  • Whatis23
    Martin, just curious. How did you prevent your users with *ALLOBJ authority from using WRKJOBSCDE?
    5,665 pointsBadges:
    report
  • TomLiotta
    ...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
    125,585 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.

Following

Share this item with your network: