limiting permissions on a outq

How can I control permissions on an outq so users can't delete specific files?

Can I create a group profile and attach it to the outq?


Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

You have a few options you can secure the outq using a auth list and also in the user profile you can make sure they do not have  special authority *SPLCTL  without this authorty they cannot mannage anyone elses spool job
dprice7Author Commented:
Since certain users have a group profile that contains *splctl I would like to know more about the auth list.
Yes, it's critical that _ONLY_ those who _MUST_ be able to access _EVERY_ spooled file have *SPLCTL. This is one of the "special" authorities and can therefore override any private authorities. If a group profile has *SPLCTL, then the group members also have it.

Given SOX, HIPAA, California Privacy Act, etc., it's hard to imagine any good reason for more than two profiles in the entire system having *SPLCTL. One would be QSECOFR; another would be an operations-oriented profile that would perhaps be a supplemental group for an operator or two or even the target of a 'swap profile' operation for emergencies.

Also, *JOBCTL special authority can give access to otherwise unsecured spooled files, but a significant degree of granularity is available to control *JOBCTL users.

Granularity is achieved in a number of ways.

Output queues can have authorities assigned; if you aren't authorized, you don't get access to anything on the queue. (Except you can always access your own spooled files via routes such as WRKSPLF without reference to an outq.)

Output queues also have attributes. Three in particular are useful -- DSPDTA(), OPRCTL() and AUTCHK().

DSPDTA() can be *NO, *YES or *OWNER. This specifies whether users who have authority to read the queue itself can display the data of any file on the queue or only the data in their own files.

OPRCTL() can be *YES or *NO. This is used to decide whether *JOBCTL special authority is extended to include spooled file operations against _this_ output queue. If *NO, the *JOBCTL won't get you access to others' spooled files on this queue.

AUTCHK() can be *OWNER or *DTAUT. This decides what type of authorities to the _output queue_ are needed to allow the user to control all the files on the queue (unless *SPLCTL or *JOBCTL has already trumped all or some authorities). If it's *OWNER, then the output queue owner is the only one in control. ("Owner" can be adopted or can be through group membership.) Otherwise, anyone with data authorities to the queue can control it.


p.s. Start by removing special authorities and then adding various regular authorities or attributes as needed.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

Work with Authorization Lists (WRKAUTL) is a great tool to group access for users.  Once you secure your outq with one of these only those in the list have access except for one other group.   That would be the users with *SPLCTL or *ALLOBJ  so limit this            
             Object    List
User        Authority  Mgt  
QRDARS400   *ALL        X  
QRDARSADM   *ALL        X  
*PUBLIC     *EXCLUDE        
Please note that an *AUTL can _NOT_ stop a *SPLCTL user from accessing spooled files on an output queue.

Although you can restrict a *SPLCTL user from referencing a *EXCLUDE output queue on a command such as WRKOUTQ excludedoutq, it is not necessary to access spooled files by referencing any outq at all. Spooled files can be accessed by job name or by user name for example, among many other ways. Since the outq object is not referenced when you enter a command such as WRKSPLF *ALL, it doesn't matter in the slightest if you're not authorized to the queue.

dprice7Author Commented:
Which brings me right back to the original question how can I secure spoolfiles if the users are part of a group profile that was set up because it lets the group profile with *splctl be the owner of all the objects in the application?

If I take away the group profile then the users will no longer be able to use the app and since that is not a viable solution in the short term I wanted to see if there was a way around it that I could secure outq's and spoolfiles separately.

There is no reason for the group profile to have *SPLCTL in the first place; this gives control of _ALL_ spooled files on the system to every member of the group, not just spooled files for the group. Everything that must be done can be done without it.

Tell the things that need to be done that you've seen can't be done without *SPLCTL, and we'll provide the instructions for the problem(s) you list.

Also, please provide your OS/400 version/release since one or two things changed in recent releases.

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
IBM System i

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.