OS/400's robust security architecture lets you specify security authorization at a variety of levels -- from the individual profile level to the group profile level and even supplemental group profile level. If, however, your system has default setups for *PUBLIC authority that are too broad in nature, all the little details at the other levels could easily be frustrated. It is important to understand how your *PUBLIC authorities are set and to review them periodically.
On my system, I have a couple of user-defined PDM options to aid in checking and updating security while viewing objects in PDM. These are "DA" for the Display Object Authority (DSPOBJAUT) command, "EA" for the Edit Object Authority (EDTOBJAUT) command and "GA" for the Grant Object Authority (GRTOBJAUT) command. Some of these may be shipped from the factory. In case you don't have these, the commands that are behind these user-defined PDM options are as follows:
DA DSPOBJAUT OBJ(&L/&N) OBJTYPE(&T) EA EDTOBJAUT OBJ(&L/&N) OBJTYPE(&T) GA GRTOBJAUT OBJ(&L/&N) OBJTYPE(&T)
When viewing objects within the PDM framework, these three abbreviations can help you get a quick understanding of how your individual object security is setup for enforcing your object access policies. If you want to check a series of objects, you can use the F17 subset function, enter one of these options on the first line of the display, press F13 to have PDM transfer the option to all of the lines in the subset and then just press ENTER to show the setup for each object in your list.
I can tell you from experience, however, that this can get old very quickly. If you want to do a review of how your *PUBLIC authority is currently implemented, OS/400 contains a very easy to use reporting function that will create listings for you that you can scan by eye to see where any problems might be lurking in your security configuration.
The OS/400 command that generates these listings is the Print Publicly Auth Objects (PRTPUBAUT) command. Using this command, you can generate listings for objects on your system and do a quick review of the *PUBLIC authority setup. Your first task should be to review how your libraries are setup for *PUBLIC access. You can use the following command format for this listing:
If you prompt the command, you can use HELP to check the additional parameters before running the command. The report that is generated will tell you what user profile owns each library, whether or not there is an authorization list active and what the *PUBLIC setting is for the library. If you see libraries on your system that you expect to have restricted access with *PUBLIC *ALL as the authorization setting, you might want to look into making a change at the library level.
Once you have reviewed how your libraries are set up, you can then run the following command to review objects within specific libraries. For example, you can use the following command format to look at all *FILE objects in a specific library:
PRTPUBAUT OBJTYPE(*FILE) LIB(MYLIB)
This will generate a report in the same format as the report at the library level, but for all of the objects in the requested library (MYLIB) that are for the specified object type (*FILE). Again, if this is a library that contains objects that should have a narrowly defined set of users and you find objects with *PUBLIC *ALL or perhaps even *PUBLIC *CHANGE, then some changes may be needed in your security access configuration.
If you have specific questions about anything mentioned in this article, feel free to contact me directly at: firstname.lastname@example.org.
Rich Loeber is president of Kisco Information Systems Inc., in Saranac Lake, NY. The company is a provider of various security products for the iSeries market.
================================== MORE INFORMATION ON THIS TOPIC ==================================
The danger of indiscriminately assigning special authorities
In this tip, security guru Dan Riehl explains the special authorities and points out the main exposures if they are not assigned judiciously.
Preventing users from uploading data
One user writes, "I'm in the process of implementing ODBC on my iSeries. How can I prevent users from uploading data back to the iSeries? I have no problem with my users downloading data; I don't want them uploading data. Also can security be placed at the library level?" Security expert Carol Woodbury offers some advice.
.94NaacJbM37.2@.ee84639/1581>Securing a library from adopting authority
"Benallgood" was trying to secure a library containing payroll information. He secured the library with an authorization list and set the public authority on both the library and authorization list to *exclude. However, when doing a WRKLIB or query on the library from a user profile not in the authorization list, he could still access it. Search400.com site expert John Brandt and "edfishel" were on hand to offer some advice.
The adopted authority problem
Objects, such as programs, on your iSeries can adopt authority from owners, from users, from other programs or even other systems. Is this a problem? Security guru Rich Loeber says it can be. It would be in your best interest to understand what programs have authority to bestow on those to whom it should not be granted.
This was first published in February 2004