Manage Learn to apply best practices and optimize your operations.

Command line security considerations -- Part 1

Part one of this tip looks at how to limit user accounts through profile restictions and menu options to improve command line security.

When a user on your iSeries system signs on to a terminal session, he will be presented with a command line. Given enough security permissions, a user can do just about anything from that command line -- if he is inquisitive enough. This tip discusses several options for controlling what a user can do, and more importantly what he cannot do, when he is presented with a command line.

More Information

Controlling use of the command line begins with the way your user profile is set up -- specifically, the option to "Limit capabilities" (LMTCPB). That will define what, if any, controls the system imposes over use of the command line. Unfortunately, many systems just use the default "*NO" setting for this value and that leaves the command line wide open for use -- and abuse.

There are three possibilities for the LMTCPB parameter in the user profile:

  • *NO - means there are NO limits on the user of the command line. In addition to processing commands from the command line, the user can also make certain changes to their user profile that you might not want them making.

  • *PARTIAL - this is a little better than the *NO option and it limits certain actions the user can take at sign on and from the command line, but they can still run commands.

  • *YES - this is the best option for most of your users. The user cannot specify different parameters for menu and library from the sign-on screen and they cannot change the setup for their user profile. The user also is not permitted to run any OS/400 commands from the command line.

But, your user says, "I need to be able to check my output reports using the WRKSPLF or WRKOUTQ command!" This is a common issue in some shops, but setting the LMTCPB for the user profile to *NO or *PARTIAL is not the answer. If a user needs to use a very limited set of OS/400 commands, the best way to solve that issue is by creating menu options for them to use. The user can continue to run the commands from the menu option with no problem.

One thing to also be careful about is the starting menu you present to your user. Again, the default that comes from IBM is to give your users access to the OS/400 MAIN menu in QSYS. This menu can easily lead an inquisitive user to options and capabilities that you don't want them seeing or using. Even by following the menu options, a user can easily get into areas where they just don't belong. Make sure you specify a starting menu that strictly limits where the user can go. Spend some time testing your menu structures to make sure they do not lead a user to capabilities that they should not be granted.

In Part II of this article, we'll take a look at how to effectively limit use of commands in OS/400 when you absolutely have to let users have access to the OS/400 command line.

If you have any questions about this topic, you can reach me at, I'll give it my best shot. All e-mail messages will be answered.

About the author: Rich Loeber is president of Kisco Information Systems Inc. in Saranac Lake, N.Y. The company is a provider of various security products for the iSeries market.

Dig Deeper on iSeries system and application security

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.