Re: NO queries in QGPL please!!

[John Earl <johneARL@xxxxxxxxxx>]

DAsmussen wrote:

> John,
>
> In a message dated 98-03-19 19:03:08 EST, you write:
>
> > 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
>
> Dang, John!  One mistake in nearly three years, and you guys have got me
> paranoid.  Ya' know, just because you're paranoid doesn't mean "they're" _NOT_
> out to get you ;-).  I signed back on to verify the information I _JUST_
> checked.  Device descriptions and message queues are, as stated earlier by
> Dave Shaw, created in QSYS.  OUTQ's are created in QUSRSYS.

How embarrassing!  It' bad enough to make a gaff like this, worse when you make 
a
gaff when trying to correct someone else's :(  My apologies.

Yes, device message queues are created in QSYS.  User Message queues are created
in QUSRSYS.

In any case, their still is no need to allow end-users to create objects in 
QGPL,
agreed?

jte





>
>
> >  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.
>
> Agreed here, but the only limitation is for OUTQ's...
>
> >  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.
>
> No, no, no, no, no ;-).  I _by no means_ meant to imply that security
> shouldn't be tightened down.  I am a _HUGE_ (no smart aleck comments about my
> stature from those that I've met, please) supporter of security issues.  I
> attend those marathon security BOFs at COMMON, and try to help make the /400
> more secure when I can.  I agree with Steve Glanstein's position that security
> level 50 should be used unless you're going to lose vendor support over it --
> and that you should look at dropping vendors that would do so.
>
> >  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).
>
> Agreed, and _this_ is what I meant to imply.  Be careful, use a "development
> box" for testing if you can -- many of you have a Y2K box installed that would
> be perfect.
>
> JMHO,
>
> Dean Asmussen
> Enterprise Systems Consulting, Inc.
> Fuquay-Varina, NC  USA
> E-Mail:  DAsmussen@aol.com
>
> "It is impossible to make anything foolproof, as fools are so ingenious." --
> Anonymous
> +---
> | 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
> +---



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