RE: NO queries in QGPL please!! -- MIDRANGE-L

Device message queues are created in QSYS, user message queues in
QUSRSYS !  
Agree totally with what you said re security.     :-)


Neil Palmer                                AS/400~~~~~      
NxTrend Technology - Canada   ____________          ___  ~     
Thornhill, Ontario,  Canada   |OOOOOOOOOO| ________  o|__||=   
Phone: (905) 731-9000  x238   |__________|_|______|_|______)   
Cell.: (416) 565-1682  x238    oo      oo   oo  oo   OOOo=o\   
Fax:   (905) 731-9202       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
mailto:NPalmer@NxTrend.com    AS/400  The Ultimate Business Server      
http://www.NxTrend.com

> -----Original Message-----
> From: John Earl [SMTP:johnearl@lns400.com]
> Sent: Thursday, March 19, 1998 12:54 PM
> To:   MIDRANGE-L@midrange.com
> Subject:      Re: NO queries in QGPL please!!
> 
>   
> Paul wrote: 
>         
>       John Earl wrote: 
>       If you don't want someone to do something on the AS/400, you
> secure against that event.  Then it's done, end of hassle. 
>               No new batch processes to manage or monitor.  No
> confused, angry or hurt users, and no arguement.  If the rules for
> your system are that no user objects belong in QGPL, then use OS/400's
> security to enforce those rules. 
>               Better to take preventative action and prohibit users
> placing objects in the library in the first place by removing their
> *ADD authority to the library.  The users get immediate feedback, the
> queries get put somewhere else, and you don't have another IS overhead
> process to babysit. 
>                
>       This is precisely what I'd like to do, but other subscribers of
> this list have cautioned me against it - Dean warned me: "Of course,
> this will cause you other problems -- 
>       QAUTOCFG device message queues cannot be created, for one."
>         
> 
> Dean is a smart guy, but he's wrong on this point.  First off, message
> queues for devices are created in QUSRSYS, not QGPL, so there will be
> no conflict with users doing their own autoconfig 
> Second, If you did the same thing to QUSRSYS that I proposed to QGPL,
> (limit users ability to add objects to it), the only thing that wouild
> be disabled is end-users ability to autoconfig devices.  This is not a
> bad thing.  Autoconfig is a handy tool for IS staff, but good security
> practices would counsel against leaving it on all the time. 
> Third, and this one really gets me, is the general notion that
> something bad (we don't know what, but we're sure it's bad) might
> happen if you tighten down security.  I'm not picking on Dean, because
> I hear this from many sources.  And I know that this comes from the
> (percieved) limited ability to test security changes, especially ones
> like this that affect IBM objects .  Many people have nightmares about
> the time that they changed some security value and ended up disabling
> hundreds of people. 
> But just as with any other change on your system, you should test
> security changes on a small scale before you roll out a massive
> change.  When you can't create a separate test envirnoment (like this
> QGPL change), you can pick a small group of users, tell them what
> you're doing, and make the change effective for just those users.  You
> can then determine whether the change has any adverse affect (I'd be
> shocked if you found one in this instance). 
> jte 
> -- 
> John Earl Lighthouse Software Inc. 
> 8514 71st NW Gig Harbor, WA 98335 
> 253-858-7388 johnearl@lns400.com 
> Without Lighthouse Network Security/400, your AS/400 is wide open. 
> -- 
>  
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@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
+---