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 thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.