× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: QPJOBLOG security
  • From: John Earl <johnearl@xxxxxxxxxxxxxxx>
  • Date: Thu, 02 Nov 2000 13:19:53 -0800
  • Organization: The PowerTech Group



rob@dekko.com wrote:

> How can I prevent people from deleting their joblogs?
>
> We are using the IBM utility to clear these out.  Too many times I've ran
> into problems and discovered the joblogs gone.  I had to secure the command
> CLROUTQ because of one offender.
>
> Closest I've come to is creating my own DLTSPLF command and placing that
> above QSYS in the system library list.  That will probably hit the
> majority.  However, any bets that this wouldn't stop Op's Nav?

Years ago we didn't extensive research on this topic in order to determine how 
to
prevent a user from deleting the audit trail that DBU and DFU would generate 
when
data was changed by programmers.  We came to the conclusion that a user will
always have authority to delete a spool file that they own.  You just can't stop
it.  We were able to significantly hinder deletion to the point where we were
reasonably sure it wasn't happening, but could not completely guarantee that 
we'd
stop it. The essense of the solution was this...

Attach a data queue to the outqueue in question.  Every time a spool file 
appears
in the outq in the 'RDY' status, an entry is generated into the data queue.  A
never ending job (running under a profile caleed NETSPOOL, having *SPLCTL 
special
authority, and no one is authorised to this profile or the objects that it owns)
would then pluck the entry off of the out queue and SNDNETSPLF to another out
queue.  This essentially changes the spool file's owner.  Now all that is needed
is to properly secure the new spool file (outq really) so that the user can 
read,
but not change or delete the spool file.

A bit convoluted, but it was fairly effective.  If it's a solution that you are
interested in, and you're patient, I'll scurry around and try to find the CL 
code
that made all of this work.

jte

P.S.  For you security sleuths out there: there is at least one potential
security flaw in this design that made us unable to gauranty that no one deleted
their own spool files.  Can you find it?






>
>
> Rob Berendt
>
> ==================
> Remember the Cole!
>
> +---
> | 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
> +---

--
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
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.