All,
I'll try to give more backgroud so it might become clearer... fact is that we have support people that are entitled to a limited set of OS/400 commands (lets say about 50 or 100), with additional restrictions (for example some commands are not allowed on certain libraries, files, ...).
If we would open up normal command line access I have an issue that they can execute thousands of commands instead of those 50, and perform tasks on all objects. While I understand that object security is the best solution it is a huge (nearly impossible) task to secure every single command or object.
That's why I build the fake command line which validates the command entered against a list of generic expressions (which is so flexible that I can allow a user or group to copy only a file starting with an X, three characters long from a library starting with Y to an object that should be between 5 and 10 characters, start with Z and end with a digit to name something stupid). In addition I have rewrite rules that allow me for example to automatically subdmit the entered command, run it with adopted authority and even process it as an SQL (yes, users can just type "select * from table" or any other SQL on the command line).
So I hope you understand that I don't need a seperate exit for ADDPFM and ADDRPYLE, neither do I want to register my program on the exit for every single command to just block it (for those that are allowed it was an acceptable solution, but enough not enough - you wouldn' be able to execute it yourself, you can only "analyze" it).
If people do get a command line one way or the other they can't do anything due to the LMTCPB.... but this is annoying because they always need to return to their initial command line. Also for example a tool which again presents a command line doesn't work as I can't control that command line.
There are more drawbacks for not being able to have control over the command processor... but the mail would become too long to explain ;-)
Kind regards,
Paul
________________________________________
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxx> on behalf of Buck Calabro <kc2hiz@xxxxxxxxx>
Sent: Monday, August 29, 2016 18:36
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Replace command processor
On 8/29/2016 9:59 AM, Paul Nicolay wrote:
I don't have to write code for every single command... I do have that code already and it is based on regular expressions which is just generic (it runs already for several years on my "fake command line", the only issue is that I need to keep the user on that one).
So I don't understand why I would need to write stub code for individual commands... all I need is the string that is entered on the command line...
You said that you needed to handle every command on the system. I can't
personally imagine how one processing program could handle (for
example's sake) ADDPFM, ADDRPYLE, and DSPTAP. So I overstepped my
bounds and suggested a separate processing program for each command.
But no, there's no particular architectural reason to do that.
I wonder if the exit program would allow me to register thousands of entries for every single command on the system (I don't think I can specify *ALL/*ALL on it).
The question of using the Command Analyzer Change exit program may be moot:
http://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_72/apis/xcachg.htm
Exit programs may not be registered for the following system commands:
CALLPRC
CALLSUBR
CHGVAR
CLOSE
CNLRCV
COPYRIGHT
DCL
DCLF
DCLPRCOPT
DO
DOFOR
DOUNTIL
DOWHILE
ENDDO
ENDPGM
ENDRCV
ENDSELECT
ENDSUBR
GOTO
IF
INCLUDE
ITERATE
LEAVE
MONMSG
OTHERWISE
PGM
RCVF
RETURN
RTNSUBR
SELECT
SNDF
SNDRCVF
SUBR
TFRCTL
WAIT
WHEN
In addition, exit programs may not be registered for these commands:
CALL command.
Commands that are restricted to use by the CL compiler when
compiling for a previous release.
Commands in libraries QSYS38 and QUSER38.
--
--buck
Visit wiki.midrange.com and register for an account. Edit a page that
helps you, and because it's public, you'll help someone else, too!
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
midrange.com
