.st0{fill:#FFFFFF;}

I love a big fat spliff 

 July 21, 2011

By  NickLitten

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?

NickLitten


IBM i Software Developer, Digital Dad, AS400 Anarchist, RPG Modernizer, Shameless Trekkie, Belligerent Nerd, Englishman Abroad 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 remember: If at first you don't succeed then skydiving probably isn't a hobby you should look into.

Nick Litten

related posts:

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}
__CONFIG_colors_palette__{"active_palette":0,"config":{"colors":{"cff50":{"name":"Main Accent","parent":-1},"a344d":{"name":"Accent Transparent","parent":"cff50"}},"gradients":[]},"palettes":[{"name":"Default","value":{"colors":{"cff50":{"val":"var(--tcb-skin-color-0)"},"a344d":{"val":"rgba(46, 138, 229, 0.85)","hsl_parent_dependency":{"h":210,"l":0.54,"s":0.78}}},"gradients":[]},"original":{"colors":{"cff50":{"val":"rgb(0, 178, 255)","hsl":{"h":198,"s":1,"l":0.5}},"a344d":{"val":"rgba(0, 178, 255, 0.85)","hsl_parent_dependency":{"h":198,"s":1,"l":0.5}}},"gradients":[]}}]}__CONFIG_colors_palette__

Get In Touch

I’m always looking for awesome input, feedback and critique!

>