A few years ago I worked with the lead developer of RJS Software’s WebDocs-iSeries document management solution to see whether we could use authorization lists to provide a standardized method for securing WebDocs-iSeries objects on the iSeries.
You see, the iSeries is strange in that it has two file systems that are both “native”, and WebDocs-iSeries uses both. The first and the original, is the library/object model that has been around since the early System/36 days. A master library, QSYS, contains system objects and all other libraries, which may themselves contain objects but not libraries. This produces a very flat file structure, with any object being fully specified simply by naming the library it is contained within and its object type.
Later, a UNIX-like file system was added (IFS or Integrated File System) but without removing the old file system; instead, libraries appear as UNIX directories with objects appearing as files and object types their extensions. Native applications were blissfully ignorant of the change, and I’ve actually spoken to administrators who were similarly ignorant. In addition, many iSeries applications do not explicitly work with the IFS.
With V5R3, IBM switched from using its own web server on the iSeries to using the popular Apache web server. Before that WebDocs-iSeries had been storing the actual documents uploaded to it in the IFS, so any comprehensive security solution was going to have to accommodate the library/object model as well as the files and directories in the IFS. Authorization lists fit the bill perfectly.
Or so we thought. Ultimately, they proved too cumbersome for our customers and their real-world utility was minimal. But along the way I stumbled across an odd mismatch between the level of authorization that was theoretically required for Apache in IBM’s Redbook and what was actually required.
Apache on the iSeries has two primary user profiles it uses: QTMHHTTP and QMTHHTP1. The former is used for accessing the web site pages under /www for a given Apache instance, while the latter is used for executing CGI programs. Since the same iSeries job may be used for both operations, Apache switches the user profile of the job when it runs CGI programs.
What this implies is that the only files QTMHHTTP should ever need access to are those in /www. But, in fact, it traverses the directory structure of the IFS to check whether a given CGI program is present before the job switches users. Since our CGI program object is in the RJSIMAGE library, QTMHHTTP needed read access to /QSYS.LIB/RJSIMAGE.LIB/* before it would perform the switch and allow QTMHHTP1 to run the program.
While unexpected, this mismatch between expectations and actuality isn’t necessarily a problem. But paying attention to such mismatches can be educational. The Linux From Scratch project has actually made a sort of perverse game of this form of pedagogy, with their “User Based Package Management” approach. It looks masochistic because it is, but it’s also enlightening: verifying security is all about attention to such details.
Last I checked, V7R1 behaves the same way, and the Redbook still hasn’t been updated. So it goes …