Yes thats right. *SPLFS. IBM Spool Files. I sample several spliffs every day, so I want to keep them secure:
Spool files and Printer security
Question: I want to set up user profile who just can display spool file but who can not delete it.
Answer 1. Spool file security is quite a bit different than usual AS/400 security.
First, The user should not have any special authorities, especially not *SPLCTL *JOBCTL or *ALLOBJ. (OK their are ways to secure an outq when the user has some of these special authorities, but I’m giving you the fast path).
Then create (or change) the OUTQ’s in question so that “Authority to Check” parameter is eqaul to “Data Authority” (Ex: AUTCHK(*DTAAUT)) and the “Display Data” parameter is equal to yes (Ex: DSPDTA(*YES)).
Then set the object authority on the outq to *USE for that user. This will give the user read authority only.
Question: We have some output queues we wish to secure. The problem is several users have *SPLCTL and *ALLOBJ. We want to secure an outq such that only specific users can view/change spool files in that queue. I’ve created an outq with public *EXCLUDE, and added an authorization list to it. I’ve revoked my ownership of the queue to QSECOFR. Even if my name is not on the authorization list, I can still view and change spool files in this out queue. My profile has *ALLOBJ and *SPLCTL, among others. What are my options?
Answer 1. remove *ALLOBJ
Answer 2. You’ve almost got the worst of both worlds here. If a user has *ALLOBJ authority, there is no way to prevent them from seeing an out queue. You can however prevent an *ALLOBJ user from seeing or changing _entries_ in a queue by creating the queue like this:
CRTOUTQ OUTQ(QGPL/SECOUTQ) DSPDTA(*OWNER) + AUTCHK(*DTAAUT) OPRCTL(*NO) AUT(*EXCLUDE)
(Note: example shamelessly lifted from the Security Reference manual) In this example, only those people who own a file may access the file…. unless the user has *SPLCTL special authority.
*SPLCTL compounds this issue. Even if you take away *ALLOBJ, *SPLCTL can be viewed as *ALLOBJ for spool files. Just as it’s impossible to protect an _object_ from an *ALLOBJ user, it is also impossible to protect a spool file from a *SPLCTL user.
By way of a solution, you might consider taking away *SPLCTL authority from all interactive users. One view is that *SPLCTL is almost never needed for an interactive profile. You might use it for a dedicated batch processes that works with spool files, but for an everyday interactive profile it is definitely overkill. A user with *JOBCTL special authority can work with the entries on an outq that is defined as *OPRCTL(*YES). Isn’t this enough authority for what they need to do?