Ever wonder whether you should give a user *JOBCTL or *SPLCTL special authority? It should be an easy decision -- *JOBCTL special authority is for managing jobs and *SPLCTL special authority is for managing spooled files, right?

Wrong. Even though syntactically, they seem as if they are pointed in those directions, it's not always the correct way to make a decision on which one to use.

That is probably why in my company's annual report, "State of the System i Security," *SPLCTL is always the single most widely-granted special authority. In truth, both *JOBCTL and *SPLCTL special authority provide remarkably similar capabilities, and the differences between the two are astoundingly slight.

*SPLCTL is essentially *ALLOBJ for spooled objects: jobs on a job queue, spooled files on an outqueue, job streams on a diskette (does anyone still use the old STRDKTRDR command?). A user with *SPLCTL special authority will always have the power to start, stop, hold, alter, and read all spooled objects on the system. For that reason alone, I can think of no reason why a living, breathing person needs *SPLCTL special authority. Occasionally, there is reason to provide *SPLCTL to a service-type profile that must have rights to work with all spooled files on a system, but in those cases, this authority would be possessed by a user profile that has no password and never actually signs on. If this authority is instead assigned to a user profile that can sign on to your system via telnet or OPSNAV, then data in your outqueues and jobs in your job queues can never be completely secured. If ever you are tempted to give a user *SPLCTL special authority, resist the urge, and give them *JOBCTL special authority instead.

*JOBCTL is the less powerful sidekick to the super power *SPLCTL. *JOBCTL provides start, stop, hold, alter, and read access to jobs on job queues and spooled files on outqueues, but there is one critical difference--users with *JOBCTL special authority can be excluded from exercising their super powers over certain job and output queues. There is a seldom-noticed parameter on every job queue and output queue called OPRCTL. If OPRCTL is set to *YES (the default), then users with *JOBCTL special authority can start, stop, hold, alter, and read entries on the queue even if you have given them *EXCLUDE authority to the job queue or output queue object. Alternatively, if you change the OPRCTL flag to *NO for a given queue, then users with *JOBCTL special authority need the proper object level authority in order to work with the entries on the queue. This means you can provide your system operators with *JOBCTL special authority and be assured that they can help users with run time and printing challenges--while at the same time ensuring that the CREDITCARD and PAYROLL outqueues are off-limits to curious or nefarious staffers.

There is one more detail about *JOBCTL special authority that you should know--users need *JOBCTL special authority in order to run the PWRDWNSYS or the ENDSBS *ALL commands. That doesn't mean that giving a user *JOBCTL also gives them PWRDWNSYS, it just means *JOBCTL is one of the requirements to run those commands. So, to head off any potential trouble in this area, investigate the object authorities on the PWRDWNSYS and the ENDSBS command to make sure that only the users that need to run those command are authorized to do so.

Removing *SPLCTL special authority from end users is imperative if you have sensitive data on your system. Therefore, *JOBCTL is always a better option.

Editors Note: John Earl referred to the document "State of System i Security – 2008" compiled and published by The PowerTech Group. You can download the study here.
The download requires you to supply contact information.