Yes thats right. *SPLFS. IBM Spool Files. I sample several spliffs every day, so I want to keep them secure:
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?
IBM i Software Developer, Digital Dad, AS400 Anarchist, RPG Modernizer, Alpha Nerd and Passionate Eater of Cheese and Biscuits. Nick Litten Dot Com is a mixture of blog posts that can be sometimes serious, frequently playful and probably down-right pointless all in the space of a day. Enjoy your stay, feel free to comment and in the words of the most interesting man in the world: Stay thirsty my friend.
Don’t hardcode library names in your TURNOVER SQL source #youbigsilly
GETSPLF and PUTSPLF – read and write spools to physical files including all Advanced Function Printing Data Stream (AFPDS)
How to move all spool files to a new output queue on the IBMi
How to Install IBM Access Client Solutions (ACS)
IBM i Data Obfuscation – Making Data Foggy Murky and Squinty
How to rename Fresche (BCD) Presto Library – XL_PRESTO
What is AS400 modernization?
IBM i ACS 5250 EMULATOR FONT – and other ridiculous mumbo jumbo
IBM i SQL statement to convert or compare hundred year date format