Security and Systems Management Newsletter for the IBM i             May 28, 2014 - Vol 4, Issue 9
Security Training from

Security software from Powertech

Skyview Partners

Security Training from The 400 School

Feature Article

Using CL Command Exit Programs Part 1

By Dan Riehl -

Ever since the first version of the CPF operating system was shipped with the System/38, system administrators have grappled with the problems inherent in customizing the IBM supplied Control Language command set for the System/38 and later for the AS/400 and System i. One major source of irritation was that when a new release of the operating system was installed, any changes made directly to the IBM supplied commands in the QSYS library were obliterated. So, for each new operating system release, the system administrator would have to re-apply all of the command changes.

Over time, we all got a bit smarter and figured out that we could make a copy of the IBM supplied command in our own library, and modify the copy. By strategically placing our own library, perhaps named ALTQSYS, ahead of QSYS in the system portion of the library list, we could effectively override the IBM supplied version. So when a new release of the operating system was installed, it would replace the IBM supplied version of the command in the QSYS library, but leave our customized version in our ALTQSYS intact.

Since Control Language commands do not often undergo fundamental changes that impact the majority of us, the ALTQSYS copy of a command created at a previous release of the operating system normally functioned correctly. However, there were certainly exceptions, in which the ALTQSYS version of the commands would fail after installing a new release of the operating system.   Still not a perfect solution, but normally manageable.

If you examine the system portion of the library list on your System i using the command DSPSYSVAL QSYSLIBL, you will most likely see an ALTQSYS library ahead of QSYS. You will many times also see the name of a vendor supplied library. Some System i software vendors seem to make a habit of placing their library on your system library list ahead of QSYS in order to override the processing of the IBM supplied command set. This is particularly true in the case of software utility and tool vendors.

Most of us have accepted the fact that we need libraries above QSYS in our library list to support our customized versions and vendor supplied versions of CL commands and other objects. But there is an inherent danger in this scheme. Any library existing above QSYS on the system library list can potentially open the System i to a severe security exposure; the Trojan Horse. If a user can create or change objects in a library above QSYS, or in QSYS for that matter, that user can introduce their own program or command that can do major damage to your system.

In an attempt to eliminate the need for libraries above QSYS, IBM, in OS/400 V4R5 enabled a facility that may make it possible to remove the libraries above QSYS from the system portion of the library list. I say may, because the support provided as of OS/400 V4R5 deals specifically with CL command customization, but does not account for other customized objects that may need to appear before QSYS.

The enhanced support as of V4R5 was the CL command analyzer exit points. These exit points provide the ability to change the processing done by a Control Language command at run-time.

CL Command Exit Point Programs

CL has always had validity checking programs and command processing programs. Over the years IBM has added prompt override programs, prompt choice programs and prompt control programs. Back in V4R5, IBM added the support for command analyzer exit programs that further enhance CL's capabilities, and more importantly, can enhance and simplify your system administration, configuration and security.

In this article, the focus will be on the command analyzer change exit point, the retrieve exit point will be covered in a later issue, as will the new support for specifying the time(Before/After) of the command exit point programs. We'll also look at some Command Exit Point Secrets that are not documented features, but with some testing and research, you can do magic with CL Command Exit Programs.

Read More . .

In This Issue

Featured Article - Command Exits Part 1

Security Shorts - Library Authorities

Industry News and Calendar

Security Resources

Quick Links

Search Security Site for IBM i and i5/OS

SecureMyi Website

Security Training from The 400 School

SecureMyi Newsletter Home/Archives

Our Newsletter Sponsors

Platinum Sponsor

    The 400 School, Inc

Gold Sponsor


    Skyview Partners, Inc

Silver Sponsor

    Cilasoft Security Solutions

IBM i Security Resources

IBM i Security Videos - SecureMyi

SecureMyi Newsletter Archives

Search Security for IBM i

IBM i Security Ref - 6.1

IBM i Security Ref - 7.1


QAUDJRN Entry Layouts

RedBook - Security Guide IBM i

Open Security Foundation - DataLoss DB

National Vulnerability Database - NIST

PCI Data Security Standard


HIPAA Resources

HITECH Enforcement

CISSP - Certification

Follow SecureMyi on Twitter

Follow SecureMyi on YouTube

Software from Cilasoft

Security software from Powertech
Security news and Events

Live Security Related Webcasts and Training for IBM i

June Events

Live Hands-On - IBM i System Administration and Control Workshop
with Dan Riehl

Training Workshop - June 2-6 - Presented by The 400 School, Inc.
Dan Riehl presents this 5-Day Live Online Hands-on Workshop.
More Information and Register to Attend

Coffee with Carol: with guest presenter Patrick Townsend
Encrypting Data with FIELDPROC - No Application Changes!

Live Webcast - Presented by Skyview Partners
Thursday, June 12 10:00am CDT
More Information and Register to Attend

Skyview Partners

Security Training from The 400 School

Security Shorts - Rules for Library Authorities

By Dan Riehl -

A popular misconception is that if a library is secured as *PUBLIC AUT(*USE), then this library authority provides Read-Only access to the files that reside in the library. For most of use who read this newsletter, we know that this is not true.

Here are the rules for library authorities.

*EXCLUDE Authority

If a user has *EXCLUDE authority to a library, they cannot access the library, nor can they access the objects within the library.

*USE Authority

If a user has *USE authority to a library, they can access the library, but cannot change attributes of the library, such as the library text. The user cannot add new objects to the library.

When it comes to accessing the objects within the library, the object authority is the determining factor. For example, if a user has *EXCLUDE authority to a file in the library, they cannot access the object. If a user has *USE authority to a file in the library, they have read-only access to the file. If the user has *CHANGE authority to a file, they can open the file for update and manipulate the records in the file (add, change, delete). If the user has *ALL rights to the file in the library, the user may perform all operations on the file including deleting the file. Yes, that's right. If a user has *USE authority to a library, the user can delete an object from the library if the user has *ALL authority or *OBJEXIST authority to the object.

*CHANGE Authority

If a user has *CHANGE authority to a library, they can access the library and can change some attributes of the library. Changes to some attributes require the additional *OBJMGT(Object Management) authority to the library. All of the same object rules are in effect as when the user has *USE authority to the library, but there is one big difference. If a user has *CHANGE authority to a library, they can create new objects in the library. That is the only real difference between *USE and *CHANGE authority to a library. If you have *CHANGE authority, you can add new objects.

*ALL Authority

If a user has *ALL authority to the library, the user can access the library, and may even be able to delete the library and all the objects within the library. However, if the user does not have *ALL authority, or a mixture of *OBJEXIST and *OBJOPR authority to the objects in the library, the user cannot delete those objects and therefore cannot delete the library. If a user has the authority to delete all the objects in the library, then the library itself can be deleted. All of the same rules apply to object access as when the user has *USE or *CHANGE rights to the library.

What about *ALLOBJ Authority?

When dealing with library and object authorities, you always have to take into account that some user profiles have *ALLOBJ special authority. When a user has *ALLOBJ special authority, there are no restrictions on accessing objects in your user libraries. A user with *ALLOBJ special authority can read, change and even delete any object in any user library on the system.

(Note: There are some objects that may not be deleted even by a user with *ALLOBJ special authority. For example, user profiles cannot be deleted by an *ALLOBJ user, unless that user also has *SECADM special authority.)

Sponsored Links

IBM i, iSeries and AS/400
Security Services from SecureMyi

IT Security and Compliance Group

In Depth Security Assessment of IBM i
Upgrade to QSECURITY level 40 or 50
Forensic Research and Analysis
Audit Assistance and Remediation
Security Training for IT and Audit Staff
Software Selection & Configuration
Security and Systems Programming

Live Training from The 400 School, Inc

Customized IBM i (AS/400) Training -
    Presented Live at your offices

Live Online Hands-On Workshops

ILE RPG IV Programming Workshop
RPG/400 Programming Workshop
IBM i COBOL Programming
Interactive Programming Workshops
System Operations Workshops
System Administration and Control
Security and Audit Workshops
Control Language Programming
IBM i Concepts and Facilities
Query Workshop

Security Services from

Send your IBM i Security and Systems Management News and Events!           Send your Questions, Comments, Tips and Stories

Copyright 2014 -, all rights reserved | St Louis MO 63017