Manage Learn to apply best practices and optimize your operations.

Are you using Authority Holders?

With an Authority Holder in place, you can pre-set how *PUBLIC authority will be granted when a physical file is created on your system.

OS/400 supports a feature known as Authority Holders. Authority Holders is a vestige of the days when a lot of System/36 code was run on the iSeries-AS/400 platform. A design technique frequently used on the System/36 was to regularly create and delete physical files. When those applications moved over to the AS/400, OS/400 had to make a method available to pre-designate how security on those objects would be handled. IBM's solution was to implement Authority Holders.

With an Authority Holder in place, you can pre-set how *PUBLIC authority will be granted when a physical file is created on your system. You can set that up even when the physical file does not exist on the system. Then, when your physical file is created, it picks up the *PUBLIC object authority setting from the Authority Holder that was set up.

If your system initially processed System/36 code in the System/36 Execution Environment (S36EE), then you may still have some of those Authority Holders in place. It is a good idea to review them. You can view all of the currently established Authority Holders on your system using the Display Authority Holders (DSPAUTHLR) command. If the screen comes up blank, then you're in the clear and you can stop reading this tip right here. If you do see some items displayed, you should evaluate whether or not you still need them on your system.

More Information

OS/400 does have some good protection features in place to reduce the chance that these Authority Holders will be a problem. You can only create an object that has a named Authority Holder by using the CRTPF command without compiling DDS (a program described file). If you try to create a physical file with an existing Authority Holder, your file compilation will fail. Likewise, if you try to create an Authority Holder and the file already exists as a DDS compiled *FILE object, the system will refuse to create the Authority Holder.

Problems on your system could arise, however, if Authority Holders exist and you are not aware of them. There are still situations on the iSeries where it makes sense to create program described files, and that is where your exposure might lie. Also, you may still be running some S36EE code, and it's nice to know when you have *PUBLIC authority overrides waiting in the wings to change security policies you are implementing or have already implemented.

To manage Authority Holders, there are three primary commands:

  • CRTAUTHLR -- Create Authority Holder
  • DLTAUTHLR -- Delete Authority Holder
  • DSPAUTHLR -- Display Authority Holder
  • If you've never checked your system for Authority Holders, there's no time like the present to check them out. It may not be an issue, but if you find some, it will be worth your while to investigate them to make sure they are still needed.

    If you have any questions about this topic, you can reach me at rich@kisco.com, 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.

    -ADS BY GOOGLE

    SearchDataCenter

    Close