|
Change QSYSLIBL and put a library prior to that and stick your new RUNQRY command in that. This was standard practice for all AS/400's supporting netstations prior to V4. Remember library QTODSYS? No big hairy. The question is how do you restrict that for only certain users. rwrobb@pbsilink.com on 05/18/99 05:01:17 PM Please respond to MIDRANGE-L@midrange.com@Internet To: MIDRANGE-L@midrange.com@Internet cc: Fax to: Subject: 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 +--- +--- | 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 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.