Preventing users from RUNQRY Interactively

IBM's Query/400 manual has three suggestions for preventing a user from
running RUNQRY interactively.  These are found on the web at
http://publib.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/Qb3agg00/d.0

1. Change the command RUNQRY so it doesn't allow any interactive
environments.
2. Change authority to the command so that users cannot run it at all.
3. Create a copy of RUNQRY that is restricted (as in item 1 above), put it
in a library other than QSYS, then make that library come before QSYS for
those users who should be restricted.

Unfortunately, this Appendix D does not mention the problems involved in
putting another library in front of QSYS.
Many, if not most, AS/400's have QSYS defined as part of the system value
QSYSLIBL.  That's good, since users cannot use EDTLIBL to change this
portion of their job's library list - if they could, they might
inadvertently remove QSYS, thereby killing their access to any system
command.
        The "rub" here is that you can't add a library in front of any library 
in
the SYS portion of your library list.
        A possible solution is to move QSYS to the system value QUSRLIBL.  Then,
you could perform ADDLIBLE to insert another library in front of QSYS, but
you're still exposed to accidentally removing QSYS from the list, perhaps
via a CHGLIBL command.

        A middle-of-the-road solution follows.
I created a library called QSYS_ORIG, in which I'll store the original of
any system command I am going to change.
I created another library called CUSTOMCMD, into which I'll copy the
original AND customize it.

Here's the process flow:

1. I created a copy of RUNQRY in CUSTOMCMD.  Then, I changed the command
CUSTOMCMD/RUNQRY so it couldn't run in *INTERACTIVE, *IPGM or *IREXX.
        CRTDUPOBJ  RUNQRY  QSYS  *CMD CUSTOMCMD
        CHGCMD CUSTOMCMD /RUNQRY
        Press F10 to see all parameters on this command.
        Blank out any parameters starting with *I under keyword ALLOW - Where
allowed to run

2. Then, I moved the system command QSYS/RUNQRY to QSYS_ORIG.
        MOVOBJ QSYS/RUNQRY *CMD QSYS_ORIG

I then signed on as a test user profile I have called TESTUSER.  His library
list includes QSYS_ORIG from the QUSRLIBL system value.
I performed WRKQRY, pressed F5 and it worked.
Then:
* I exited WRKQRY
* Performed ADDLIBLE CUSTOMCMD, which defaults to *FIRST (so CUSTOMCMD comes
in front of QSYS_ORIG)
* Performed WRKQRY, pressed F5, was prohibited.
* Tried submitting to batch and it ran.

All job descriptions would need to have QSYS_ORIG to provide users with
access to the original command.
Those users with restricted access would have CUSTOMCMD specified as well,
but before QSYS_ORIG.
Another idea is to create an initial program which would add the CUSTOMCMD
library to the *LIBL before QSYS_ORIG if the user Id is present in a table.
This, however, involves creating programs, file(s) and someone committed to
maintaining the data.

Of course, if your perspective is to restrict everybody except the few, the
proud, the "power users", you could give everybody access to CUSTOMCMD and
only add QSYS_ORIG to the special users' library lists.

So, this is a lot easier and safer  than changing QSYSLIBL and QUSRLIBL.
Moving QSYS to QUSRLIBL leaves the system susceptible to losing QSYS from a
job's library list if the program contains a CHGLIBL command (this replaces
the existing user library list with whatever libraries are specified in the
command.

Unfortunately, there is an exposure in moving a system command out of QSYS.
If you upgrade your operating system, moving to a new release, you'll get a
new copy of the RUNQRY command.  You probably won't notice it's there until
some user starts degrading your system again.

Then, you'll have to delete the old copy of RUNQRY from QSYS_ORIG, make a
new copy from QSYS and perform a CHGCMD command to restrict it from running
interactively again.

Still, the exposure is less than with moving QSYS to QUSRLIBL.

I'd recommend starting a file to document any/all commands you move out of
QSYS in this manner.  Record all the changes you make to the duplicated
object so that you can reestablish the same environment after an upgrade.


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