• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 506
  • Last Modified:

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?

thanks,

Don
0
dprice7
Asked:
dprice7
  • 3
  • 2
  • 2
2 Solutions
 
odumbruceCommented:
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
0
 
dprice7Author Commented:
Since certain users have a group profile that contains *splctl I would like to know more about the auth list.
0
 
tliottaCommented:
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.

Tom

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


0
Prepare for your VMware VCP6-DCV exam.

Josh Coen and Jason Langer have prepared the latest edition of VCP study guide. Both authors have been working in the IT field for more than a decade, and both hold VMware certifications. This 163-page guide covers all 10 of the exam blueprint sections.

 
odumbruceCommented:
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        
0
 
tliottaCommented:
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.

Tom
0
 
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.


0
 
tliottaCommented:
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.

Tom
0

Featured Post

Get quick recovery of individual SharePoint items

Free tool – Veeam Explorer for Microsoft SharePoint, enables fast, easy restores of SharePoint sites, documents, libraries and lists — all with no agents to manage and no additional licenses to buy.

  • 3
  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now