Re: QPJOBLOG security

Jill,

Jill Gallagher wrote:

> We worked around this.  The file QPJOBLOG would normally go to outq
> qezjoblog.  We chgd it to go to a new outq joblogoutq.  We then chgd the
> authority on joblogoutq to give public access to operational on the object
> rights and add, read and execute, but not delete or update on data rights.
> This has worked for us.  There may be a better way to do this, but it works.

Because of the crazy way that spool file security works, your users will still 
be
able to delete their own spool files by issuing the WRKSPLF, WRKJOB, WRKSBMJOB,
etc. commands.  Sure, you can secure the OUTQ, but the user doesn't have to go
through the OUTQ to get to the spool file (It's a bit of an odd relationship, 
but
the spool file doesn't actually live in the OUTQ, it lives in a multimember file
named something like QSPL/Q04079N001).  Any tool that gives them access to their
spool files without directly referencing the OUTQ (such as the mentioned
commands, Ops Nav, etc) will give the user the opportunity to delete those spool
files. simply because they own those spool files.  It's on eof those quirks of
AS/400 security.

jte



--
John Earl                    johnearl@400security.com
The PowerTech Group      --> new number --> 253-872-7788
PowerLock Network Security   www.400security.com
--


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---