Given that you can write a command processor program, so can anyone else. All someone needs to do is call their own command processor to get around yours. And really neither exit points nor routing entries nor command overrides will be able to change that. If you want to completely prevent any program that could possibly act as a command processor from circumventing your specific command restrictions, then you are going to have to have the source of them all because none of them have to use the exit points or routing entries. You are left with object security, and all that can do is allow or disallow access to an object for a particular user or group of users.

Mark Murphy
STAR BASE Consulting, Inc.

-----Paul Nicolay <paul.nicolay@xxxxxxxxxx> wrote: -----
To: "midrange-l@xxxxxxxxxxxx" <midrange-l@xxxxxxxxxxxx>
From: Paul Nicolay <paul.nicolay@xxxxxxxxxx>
Date: 08/29/2016 02:16PM
Subject: Re: Replace command processor


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,

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:

Exit programs may not be registered for the following system commands:


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.


Visit 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,
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives

Please contact support@xxxxxxxxxxxx for any subscription related questions.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by 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].