|
Dave Spooled file security is a bit of a challenge and can be murky. Here are a couple items from InfoCenter on this: Spooled file security Spooled security is primarily controlled through the output queue that contains the spooled files. In general, there are four ways that a user can become authorized to control a spooled file (for example, hold or release the spooled file): User is assigned spool control authority (SPCAUT(*SPLCTL)) in the user profile. This authority gives a user control of all spooled files in the output queues of all libraries to which the the user has *EXECUTE authority. This authority should only be granted to appropriate users. User is assigned job control authority (SPCAUT(*JOBCTL)) in the user profile, the output queue is operator-controlled (OPRCTL(*YES)), and the user has *EXECUTE authority to the library that the output queue is in. User has the required object authority for the output queue. The required object authority is specified by the AUTCHK parameter on the CRTOUTQ command. A value of *OWNER indicates that only the owner of the output queue is authorized to control all the spooled files on the output queue. A value of *DTAAUT indicates that users with *CHANGE authority to the output queue are authorized to control all the spooled files on the output queue. Note: The specific authorities required for *DTAAUT are *READ, *ADD, and *DLT data authorities. A user is always allowed to control the spooled files created by that user. For the Copy Spooled File (CPYSPLF), Display Spooled File (DSPSPLF), and Send Network Spooled File (SNDNETSPLF) commands, in addition to the four ways already listed, there is an additional way a user can be authorized. If DSPDTA(*YES) was specified when the output queue was created, any user with *USE authority to the output queue is allowed to copy, display, send, or move spooled files. The specific authority required is *READ data authority. If the user is authorized to control the file by one of the four ways already listed above, using DSPDTA(*NO) when creating the output queue will not restrict the user from displaying, copying, or sending the file. DSPDTA authority is only checked if the user is not otherwise authorized to the file. DSPDTA(*OWNER) is more restrictive than DSPDTA(*NO). If the output queue is created with DSPDTA(*OWNER), only the owner of the spooled file (the person who created it) or a user with SPCAUT(*SPLCTL) may display, copy, or send a file on that queue. Even users with SPCAUT(*JOBCTL) on an operator-controlled (OPRCTL(*YES)) output queue cannot display, copy, move, or send spooled files they do not own. See the Security topic for details about the authority requirements for individual commands. To place a spooled file on an output queue, one of the following authorities is required: Spool control authority (SPCAUT(*SPLCTL)) in the user profile. The user must also have the *EXECUTE authority to the library that the output queue is in. This authority gives a user control of all spooled files on the system and should only be granted to appropriate users. If you have spool control authority you can delete, move, hold, and release any spooled files on the system. You can also change the attributes of any spooled file. Job control authority (SPCAUT(*JOBCTL)) in the user profile and the output queue is operator-controlled (OPRCTL(*YES)). The user must also have the *EXECUTE authority to the library that the output queue is in. *READ authority to the output queue. This authority can be given to the public by specifying AUT(*USE) on the CRTOUTQ command. ============================================ Output queue security Output queues are created with a level of security determined by the value of the AUT parameter on the Create Output Queue (CRTOUTQ) command. To work with the spooled files on that output queue, you must have the appropriate authority for that output queue (as specified in the AUT parameter). For example, holding or releasing a spooled file might require one level of authority while reading the contents of that spooled file might require a higher level of authority. For more information on spooled file and output queue security, see the "Security" topic. ========================================= Then there is _Tips and Tools for Securing Your iSeries_, located at http://publib.boulder.ibm.com/infocenter/iseries/v5r3/topic/books/sc415300.pdf Page 59 has a little bit that points to Appendix D of _iSeries Security Reference_. HTH Vern -------------- Original message -------------- From: "Dave Odom" <Dave.Odom@xxxxxxxxxxxx> > Gang, > > First, I want to thank ALL those that responded to my questions. > > Second, I need to add an addendum to my requirements and some follow-on > questions: > > Addendum - I need the solution to be secure and not require a user be > given authorizations above regular user on System i5. By this I mean, > I don't want a user of any tool or solution to be able to look at any > other user's spool files or be able to change any spoolfiles to another > printer, etc., UNLESS there is some administration to the tool or > solution wherein a userid can be given access to other user's spoolfiles > EXPLICITLY via some sort of auth list. > > Follow-on questions - > > 1. In the case of a give an end user Operations Navigator(even a > selective install)... First, I thought Ops Navigator was more of a > Systems Programmer, System Operator, QSECOFR type of tool; not an end > user. Second, if given to an end user what sorts of security can be > placed on the end user to not allow them to see anyone else's > spoolfiles. Third, can users be granted SELECTED and EXPLICIT access > to another's spoolfiles via some sort of auth list? > > 2. Which of the solutions mentioned in response to my request for info, > meets the additional requirement of the addendum? > > Thanks, > > Dave > -- > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list > To post a message email: MIDRANGE-L@xxxxxxxxxxxx > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/mailman/listinfo/midrange-l > or email: MIDRANGE-L-request@xxxxxxxxxxxx > Before posting, please take a moment to review the archives > at http://archive.midrange.com/midrange-l. >
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.