If you need to create a duplicate of any object, the Create Duplicate Object (CRTDUPOBJ) command requires you to have *OBJMGT authority to the object. *CHANGE isn't enough. If the object you need to duplicate is a file, however, you can use the Copy File (CPYF) command, specifying CRTFILE(*YES).

CPYF doesn't require *OBJMGT to copy, since you're only reading the object. The CRTFILE(*YES) parameter, however, essentially duplicates the work of CRTDUPOBJ without actually running that command. This results in a security loophole you should know about.

The interesting part is this: the unauthorized user becomes the owner of the newly created file, since he created it with the CPYF command. Being the owner, he has *ALL authority to it, and can therefore change records, delete them, add to it, ad nauseam. And, he can move it to another library that's higher in the library list than the original file!

Suppose then that the file in question is the employee master file. This user runs CPYF, creates his own copy, changes his own pay rate in the duplicated file, moves it higher in the library list than the original file, and lets it sit there. Next time payroll checks are printed, the program accesses the duplicate file (with the higher pay rate), and he's got a nice raise without asking anyone.

Editor's Note: There are three methods you can use to protect yourself from this undesirable scenario.

First, revoke *CHANGE public authority to the production libraries. Make sure the public only has *USE authority. Grant *CHANGE authority (or higher) only to those users who really need it.

Even programmers may not need *CHANGE authority to the production libraries if they always work on their own libraries. In this case, assign one person (security administrator or equivalent) the task of moving new objects to the production libraries. Then give this person *CHANGE authority to the production libraries.

Second, you could qualify everything to a library in order to make sure you're using the objects you want to use. In the case of database files, issue an Override Database File (OVRDBF) command prior to running any HLL programs, using the TOFILE parameter to point to the appropriate qualified file name. Qualifying names should be avoided whenever possible, however.

Third, ensure your regular users can't run standard OS/400 commands from the keyboard. You can do this by (a) not ever giving them a command line, or (b) changing their user profiles to LMTCPB(*YES).