The i/OS Host File Server and Netserver facilities present severe vulnerabilities to your production database and applications. When your system ships from IBM, the File server is configured to be easy to use, but, vulnerable. So, it is up to you to learn how to protect the system and then to make the required changes.

There are several file sharing methods that can be implemented on i/OS. You can use iSeries Access file sharing to navigate through the IFS(Integrated File System) to locate a stream file, directory, or other object. This is typically done using the iSeries Navigator "File Systems" option. Using this type of file sharing, you can even navigate through the QSYS.LIB file system, which makes 'Drag and Drop" access available to your production libraries, files, programs, etc.

Another popular method of file serving is to use the built in support for Netserver, where you can use MS/Widows Explorer to "Map a Drive" to a shared directory in the System i IFS.

IBM has tried to make things easy by shipping the system to us with a pre-configured Netserver "Share" directed at the system's /root file system. This is very dangerous.

This /root file system is shipped with *PUBLIC *USE access. This means that any user who knows how to map a drive in Windows, can map a drive to the /root file system, in effect making available all /root directories that they are authorized to, including the QSYS.LIB directory. This directory contains all of your production database files, programs and other objects.

It is imperative that you protect the '/root' file system and that you also prevent users from accessing the QSYS.LIB file system through any file serving interface.

When users can map a drive or navigate to QSYS.LIB, or can use other iSeries Access file serving methods to access the QSYS.LIB file system, they have the ability to drag and drop i/OS files and other objects into the Recycle Bin, or right click and delete, rename, move, etc your production application objects that they are authorized to manipulate. i/OS object level authorities reigns supreme.

Users typically have no reason or need to access the QSYS.LIB file system through a client directory interface like Windows Explorer.

Here are some recommendations that you should consider.

1) Change the authority on the /root file system to *PUBLIC AUT(*EXCLUDE)

This can be done through iSeries Navigator "File Systems" option. Right click on the /root directory and set the permissions for *PUBLIC. If you have users that need access, you can add that user or their group with the appropriate level of permission.

2.) Ensure that the /root file system is not configured as a Netserver "Share".

This can be done using the iSeries Navigator option of "Servers>TCP/IP>Netserver>Shared Objects". If /root is shown as a 'Shared Object", remove the share.

3.) Change the QPWFSERVER authorization list to *PUBLIC AUT(*EXCLUDE)

Use the command EDTAUTL QPWFSERVER, and set *PUBLIC to *EXCLUDE.

The QPWFSERVER authorization list is specifically designed to control what users have access to the QSYS.LIB file system through the Host File Server and Netserver interfaces. IBM ships this list with *PUBLIC AUT(*USE) authority. However, if you set it to *PUBLIC AUT(*EXCLUDE), users will not be able to access QSYS.LIB through the file server, which is what you want.

It should be noted that the QPWFSERVER authorization list can only limit access performed through the File Server and has no affect on other servers like FTP, Remote Command, and the Database server.

For more information on using QPWFSERVER refer to the IBM Information Center [2].