More About Controlling Access to Spool Files

By Rich Loeber

In my last tip, I talked about controlling access to spool files through implementation of IBM i OS object authority at the output queue level.  In this tip, I’ll be taking a look at three additional parameters that are associated with IBM i output queues that can extend the level of control you have over sensitive reports on your system.

The three parameters in question are:

  • Display any file (DSPAUT)
  • Operator controlled (OPRCTL)
  • Authority to check (AUTCHK)

These three work to give you more control over access to spool files beyond what is available through object level controls on the output queue.

One thing to keep in mind is the proliferation of user profiles with special authority of *SPLCTL.  This is the equivalent of the evil *ALLOBJ authority, but as applied to spool files.  You should restrict granting of *SPLCTL to only those user profiles where it is absolutely required.  As you read on in this tip, remember that if a user profile has *SPLCTL authority, then they can cut through these restrictions as they will not apply (with one exception as noted).

“Display any file” (DSPDTA) is intended to protect the contents of a spool file by setting authority requirements.  There are three values available, *YES, *NO and *OWNER.  Each of these provides progressively increased levels of authority requirements to view, copy or send spool files in the output queue. *YES allows anyone with READ authority to work with files in the output queue. *NO restricts that to the owner, those with *CHANGE authority and those with *SPLCTL special authority. *OWNER further limits this to just the owner profile and any profile with *SPLCTL authority.

“Operator controlled” (OPRCTL) controls whether or not a user with *SPLCTL special authority is allowed open access to this output queue.  The default value on the Create Output Queue (CRTOUTQ) command in the IBM i OS is *YES which is why most output queues are open season for users with *SPLCTL authority.  Changing this value to *NO will force normal object authority rules to control access to the output queue.  If you have an output queue with sensitive information stored and you are concerned about *SPLCTL users gaining access, this is the key parameter value that can save the day for you.

“Authority to check” (AUTCHK) controls how users with *CHANGE authority to the output queue will be given access to change, delete or copy spool files in the queue.  When this is set to *OWNER, only the owner profile of the spool file can change or delete spool files.  Using the value of  *DTAAUT changes this control so that it looks at object level controls for the output queue.

Using these parameters intelligently can give you much added control over how users access (or don’t access) spool files on your system.  Using them in combination can be a little confusing, but if you look in your IBM i OS Security Reference manual under the Work Management section on Securing Spool Files, you will find a full page chart for this set of parameters and how they can be used in combination to achieve your specific objectives.

If you have any specific questions about this topic, you can reach me at rich at kisco.com,  I’ll try to answer your questions.  All email messages will be answered.

Controlling Access to Spool Files

By Rich Loeber

A nice feature of the IBM i OS lets you view the contents of spool files before they have been printed or distributed electronically.  For a lot of users, this saves time and paper and provides a lot of convenience.  But, not all spool files should be able to be viewed by every user.  This tip will take a look at some ways to control who is allowed to see which spool files on your system.

Print spool files are special objects on your system that are stored in the QSPL library.  You cannot control access at the spool file level on your IBM i system.  Access to the spool files must be controlled through the output queue that is associated with each spool file.

If you have sensitive or confidential information that is being stored in a print spool file, the best way to secure it is to create a special output queue (or set of output queues) that are secure to a known set of users.  To direct the spool file into the right output queue can sometimes be tricky.  IBM i generally checks the following sequence of things to direct the output from a job:

  • the printer file
  • job attributes
  • user profile
  • workstation device description
  • system print device (QPRTDEV) system value

To direct your sensitive output to the right output queue, your best bet is to specify it in the printer file being used by your application.

Output queues can be created in any library on your system.  Output queues for printer devices generally get created in the QUSRSYS library, but you are not limited by that.  To improve security, create your secure output queue in a separate library that has limited access at the library level.

Once the output queue has been created, you can then limit access to it using the Grant Object Authority (GRTOBJAUT) command and Edit Object Authority (EDTOBJAUT) command.  To specifically limit general access to the output queue, the PUBLIC setting for the *OUTQ object must be set to *EXCLUDE.  Then, in the individual user authorities, you can provide for access for specific user profiles or (better yet) group profiles.

You should also note that user profiles with the special authority of *SPLCTL will be able to view and work with spool files regardless of their access control limitations to your secure output queue.  This is a form of all object authority, but only applied to spool files.  You should limit the number of profiles on your system that have the *SPLCTL authority in order to maintain the security of your sensitive output queues.

There is also a special setting on the output queue called the “Display Data” (DSPDTA) parameter that can be used to control viewing spool files.  When you set this to *NO, then only the spool file owner profile can view the contents of the spool files in the output queue.  You can check the value of this parameter using the Work with Output Queue Description (WRKOUTQD) command to see how it is set up for your secure output queue.

There are some other intricacies that are covered in the IBM i security manual.

If you have any questions about this topic, you can reach me at rich at kisco.com,  I’ll try to answer your questions.  All email messages will be answered.

Securing Printed Output on your IBM i

By Rich Loeber,

In today’s security conscious environment, most System i shops have already locked down their systems.  Object level security is locked down and users are classified as to what they can and cannot do when they are logged onto the system.  But, securing files is only part of the problem.  If a user can’t look at a file, but they can look at processed output sitting in a print spool file, then your hard work of locking up the files is for naught.

There are several things you can do to control spool viewing.  For starters, review your user profiles to see which users have the special authority of *SPLCTL or *JOBCTL.  Both of these special authorities can give a user access to spool files.  Only security officers and system operators should have these authorities.  In a smaller shop, this might also extend to your programmers, but not always.  Generally speaking, most users should not be given these authorities unless they absolutely must manage their own print spool files and job controls.  As a first step, these authorities should be limited as much as possible, especially the *SPLCTL authority because it is not subject to any restrictions and allows the user access to all spool files on your system.

Output spool files are special objects on your system and are not, per se, created with standard IBM i/OS security controls.  The way you can control security on spool files is through the way your output queues are set up and authorized.  If you have output reports with sensitive information, you can control who can see them by the output queue where the report is stored.  Output queues are created using the CRTOUTQ (Create Data Queue) command and they can be changed using the CHGOUTQ (Change Data Queue) command.  You can view the way and output queue is configured with the WRKOUTQD (Work with Output Queue Description) command.

The user profile that creates the report can always view it and control it.  Sensitive reports should be created using a restrictive user profile to prevent widespread use of the spool file.  To impose even stricter security, there are several parameters you can set when you create an output queue that will provide more control:

  • DSPDTA    Helps to protect the contents of spool files be defining who can display, copy, move or send a spool file in the output queue.
  • AUTCHK    Defines what authority is needed to change or delete a spool file.
  • OPRCTL    Defines whether a user profile with *JOBCTL authority can work with spool files in the output queue.

Using these three parameters, you can impose very restrictive access controls to spool files associated with an output queue.  There is a good chart in the Security Reference guide that shows how the three parameters work together.  If you have never given this concept much thought, you should conduct a thorough review of how your current output queues are set up to make sure that they conform to your company’s security policies already in place.