AS/400 Command Line

15 pts.
Tags:
ALWLMTUSR
AS/400
Command line
GO
iSeries
LMTCPB
The capabilities of my user profiles are limited via LMTCPB(*YES). But the ERP package which we use (ASW from IBS) needs the command GO to work properly. So I had to set this command free for usage via ALWLMTUSR(*YES). Now of course, my users can enter GO MAIN or GO DATA and do whatever the like. They can realy harm the system if they would like to. Any possibilities to solve my problem? Many thanks.

Software/Hardware used:
AS/400, iSeries

Answer Wiki

Thanks. We'll let you know when a new response is added.

Can you just make the menu that your users are “going” to their initial menu in their user profile? Hopefully that initial menu puts them into a LMTCPB environment where they only take menu options to access other menus. If not you your ERP vendor has some real issues.

===========================================================

First, if your users actually have enough authority to harm your system by executing commands, then you have far worse problems than LMTCPB(*YES) is ever going to help you with. I haven’t worked on a system where LMTCPB() was needed for almost 20 years. It’s been almost as long since it was even relevant. Nevertheless…

Compile this command source code:<pre>
GOMNU: CMD PROMPT(‘GO ?Menu’)

PARM KWD(CMDSTR) TYPE(*CHAR) LEN(32) CONSTANT(‘go +
menu(*libl/main)’)

PARM KWD(CMDLEN) TYPE(*DEC) LEN(15 5) CONSTANT(19)</pre>

Use this command for the compile:<pre>
CRTCMD CMD( mylib/GOMNU )
PGM( QSYS/QCMDEXC )
SRCFILE( mylib/QCMDSRC )
SRCMBR( GOMNU )
ALWLMTUSR( *YES )
REPLACE( *YES )</pre>
Change CMD( mylib/GOMNU) to (QGPL/GOMNU) or some other basic library that your users have easy access to. QGPL should be the best choice.

Also, change SRCFILE( mylib/QCMDSRC ) to reference whatever source file you stored the command source in.

Note that the compilation says ALWLMTUSR( *YES ) which will allow your LMTCPB(*YES) users to run the resulting command. Also note that you will probably need to grant *PUBLIC *USE authority to the resulting command.

That will give you something to practice with. It’s a very basic command that causes the MAIN menu to appear. Usually, that will be the MAIN menu from library QSYS, but you might have a second one on your system.

Note that the length of the CONSTANT in the first PARM statement is 19 characters long. The second PARM statement has the CONSTANT value (19) to account for that length.

The command that compiles this has PGM(QSYS/QCMDEXC) in order to cause that program to run whenever the GOMNU command is executed. The QCMDEXC program accepts two parameters — a command in the first parameter and a command length in the second parameter.

In this case, the command that eventually gets executed is “go menu(*libl/main)”. You would replace “*libl/main” with the library and menu names that you want your users to get to.

Say the library is ASWLIB and the menu is ASWMNU1. You would have “ASWLIB/ASWMNU1″ in place of “*libl/main”. And instead of compiling a command named GOMNU, you might name it GOMNU1.

Note that “ASWLIB/ASWMNU1″ is 14 characters where “*libl/main” is 10 characters. That means that the total length of the CONSTANT has grown from (19) to (23), so the second PARM would need to change to match. (You could simply make the second CONSTANT always be (32) since that’s the maximum length of the first PARM. Command constants like this are always limited to 32 characters, so this technique isn’t always appropriate.)

Once you create a GOMNU1 command, your users simply type GOMNU1, press <Enter> and the ASWMNU1 menu appears.

Regardless, you <b>really</b> need to get your authorities under control. Then you can give everybody full command access and not have to worry about all of the other ways to run commands that LMTCPB() doesn’t cover.

————————————————————————————-

After thinking a bit, I realized there was a possible improvement. Here’s the new example command source:<pre>
GOMNU: CMD PROMPT(‘GO ?Menu’)

PARM KWD(CMDSTR) TYPE(*CHAR) LEN(32) RSTD(*YES) +
SPCVAL( +
(*MNU01 ‘go menu(*libl/main)’) +
(*MNU02 ‘go menu(*libl/user)’) +
) +
MIN(1) +
PROMPT(‘Menu to display’)

PARM KWD(CMDLEN) TYPE(*DEC) LEN(15 5) CONSTANT(32)</pre>

Compile it the same as the example above. The main differences are that a value is now entered with the command and that you only compile a single command rather than a different command for every menu that ASW needs your users to GO to.

The example allows the command to go either to menu MAIN or menu USER. It depends on which value is typed in for the parameter. You can compile and test it as is though it’s not the version you would give to your users.

If you want to create a version for your users, you might change the source like this:<pre>
GOMNU: CMD PROMPT(‘GO ?Menu’)

PARM KWD(CMDSTR) TYPE(*CHAR) LEN(32) RSTD(*YES) +
DFT(*MNU01) +
SPCVAL( +
(*MNU01 ‘go ASWLIB/ASWMNU1′) +
(*MNU02 ‘go ASWLIB/ASWMNU2′) +
(*MNU03 ‘go ASWLIB/ASWMNU3′) + ) +
PROMPT(‘Menu to display’)

PARM KWD(CMDLEN) TYPE(*DEC) LEN(15 5) CONSTANT(32)</pre>

That version allows three possibilities — ASWMNU1, ASWMNU2 and ASWMNU3. It also provides a default value which you might set to be the most common menu for your users.

The ‘special values’ can be whatever you like. I chose to start them with an asterisk and gave simple sequential names. If you wish, you could use the actual names of the menus — ASWMNU1, etc. — though I would recommend some difference such as the asterisk.

As before, you still keep your users as LMTCPB(*YES), you don’t need to make the GO command available to limited users, and you can add up to 300 possible optional menu names to this single command — just keep extending the list. If for some reason you <i>must</i> go beyond 300, you can always create a second command as GOMNU2 and start a new list.

Users can get to any menu that ASW needs them to reach (as long as you add it to the list in the command). You haven’t affected your security scheme at all. And there isn’t even any programming involved.

Is there anything it doesn’t cover?

Tom

Discuss This Question: 9  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • DanD
    I disagree with Tom completely on this one. When doing security audits I've always looked at LMTCPB *yes as the first line of defense on an iSeries. Users should not have command lines whenever possible and none of the Fortune 100 shops I've worked in have allowed it.
    2,865 pointsBadges:
    report
  • mcl
    I tend to agree with DanD and I see no reason to write special commands to circumvent issues wthat can easily be handled with the built-in security of the system. If the software vendor requires the use of the GO command, then the user's have to have command line access. In that case, what special authorities do the user's have, what object authorities do you have on sensitive data and what object authorities do you have on sensitive commands? Lock the system down. Just because a user can get to a menu does not automatically mean that they can use the options on that menu. Regards Mike
    2,740 pointsBadges:
    report
  • ASWDEVELOPER
    what version of ASW are you using ? ...
    405 pointsBadges:
    report
  • TomLiotta
    There are many reasons why LMTCPB() can be misleading. This Techtarget article is one example. Since it's already published at this site, there's no reason not to mention it. There's no need to mention other methods. LMTCPB() should be viewed as a temporary measure, for only as long as decent security can be applied. Once the system is properly secured, LMTCPB() no longer provides any benefit at all. In the case of the example article, the user shouldn't have been granted enough authority to clear the GL master in the first place. If proper authority is set, then the user could run CLRPFM from a green-screen command line all day long and not affect anything. Secure against what you fear. Commands shouldn't be feared; rather the results of commands should be the focus. When results are controlled, even sophisticated breaches may be thwarted. LMTCPB() has far too many workarounds. Tom
    125,585 pointsBadges:
    report
  • IveVerschuren
    I'm new to this forum and was very suprised about your prompt reactions. Many thanks to all !!! I have to admit that apart from this LMTCPB not much security was set up. I haven't taken the time yet to look closely which libraries/objects/commands should be blocked or not for my users. I even don't know yet where & how to start with it. But indeed, the harm which can be done, will probably cost me more time (& money). FYI - We are using ASW Version 4.02.
    15 pointsBadges:
    report
  • DanD
    The systems I admin have exit programs in place to control network actions. Users are not allowed ANY commands. With good object level authority, the CFO has *all to files in finance application libraries. I definately don't want him to be able to enter the command DLTF. Limiting users to programs that have gone through change control as the only way to update data insures data integrity. Where users have programs that have SQL front ends they can modify its only allowed from profiles that only have *read rights to data. DDM is only a hole if it doesn't require a profile and password. I just don't see users entering any commands.....ever.
    2,865 pointsBadges:
    report
  • Abigail
    Our practice is to set LMTCPB to *YES for accounts other than for required IT staff. In addition, I have locked down several menus (e.g. MAIN is PUBLIC *EXCLUDE. Three security administrator's have specific authorities set ) and set up authorities to menus based on job requirements.
    645 pointsBadges:
    report
  • Teandy
    <quote> Hopefully that initial menu puts them into a LMTCPB environment where they only take menu options to access other menus. If not you your ERP vendor has some real issues. </quote> I don't think that this is a real problem. The days of having one person do one job are pretty much over; unless you are working for some one with REALLY deep pockets. In today's economic environment, it is not uncommon to have one person doing several different jobs. In fact, in my experience it is getting to be the norm.
    5,860 pointsBadges:
    report
  • A4ginatl
    You need to be able to limit what your users can do. I believe you correctly restricted the users not to use the command line. That will not stop a program issueing the GO command. Your programs should be set up to issue the GO command and in this way you will be totally secure.
    95 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following