File shares are what make the IFS, or part of the IFS, available for viewing or manipulation via the network. You use file shares when you want all users on the network to have access to something. Many organizations define file shares to allow users to map a drive and easily drag and drop documents to or retrieve them from a directory on IBM i.

Editor's Note: This article is excerpted from chapter 7 of IBM i Security Administration and Compliance: Third Edition, by Carol Woodbury.

It’s important to note that although an individual file or the entire root directory may be shared on the network, users still need the appropriate authority to a directory or file to perform the intended request. Just because a file is shared doesn’t mean everyone can read it. That ability is still determined by the object authority settings on the directory or library being shared. (Yes, you can share a library!)

The list of shares that have been defined can be viewed using Navigator for i. Go to My Connections > system_name > File Systems > File Shares. (See Figure 7.5.) From this display, you can add, modify, or delete a file share. It also lists the number of users currently connected to the share. This is helpful information if you are trying to delete a share or modify it from read/write to read-only. If you want to delete the share but users are connected to it, right-click on the share name > Properties > Sessions to see the list of users currently connected. Note that this is a point in time. Users who connected earlier in the day and then disconnected won’t be listed, for example.

To create a new file share, you use Navigator. Go to My Connections > system_name > File Systems > Integrated File System, right-click the directory or library you want to share, and select Sharing. You can choose to make the share read-only or read/write. If at all possible, make the share a read-only share since it will prevent uploading to that location. You can also choose how many users can use the share at one time.

Figure 7.5: Listing of file shares

The Risk of File Shares

Prior to the onslaught of malware, the risk that file shares posed was exposing data to users in user interfaces that allowed for easy manipulation (including deletion) when you didn’t have a good object-level security scheme in place—in other words, when users had more authority than was appropriate. While that risk remains, the risk today is from malware. Specifically, the risk manifests itself when a user is attached to a read/write share and their workstation is infected by malware. At that point, IBM i looks like any other drive attached to the workstation, so when the malware is fin- ished infecting the workstation, it marches right across to whatever has been shared on IBM i. If that share happens to be to root (/), your entire system—I repeat, your entire system—is open to infection. I have seen malware that renames directories as well as ransomware that wreaks havoc on IBM i systems that have a read/write share to root. The attack is most successful when root has been left at its shipped value of DTAAUT(*RWX) OBJAUT(*ALL).

Unlike on Windows, you can’t set the access for a file share. Once you’ve created a share, it is available for all network users who possess an IBM i user profile and password.

When creating file shares, follow these guidelines:

• First and foremost, you should never create a read/write share to share root.
• You should also never create a read/write share to /QSYS.lib as this will share all of your libraries. If you need to allow sharing of the contents of a library, create the share on that library, not on QSYS.
• If you create a share to root (or /QSYS.lib), create it as read-only and add a dollar-sign character ($) on the end. (Adding a $ to the end of the file share name causes it to not be browsable on the network.)
• Create the file share directly at the point that needs to be shared, no higher.
• Create shares as read-only whenever possible.
• If you don’t want the share to be discoverable on the network, add a $ to the end of the name.

Review (and Remove) File Shares

Many systems—especially development systems—have an overabundance of file shares, meaning there are multiple shares for the same directory, shares that point to objects that no longer exist, and shares that are no longer in use. Most of the shares have been added without any realization as to what is being made available to the entire network.

To prevent users from being able to create file shares, change the QZLSADFS (Add File Share) and QZLSCHRS (Change File Share) APIs from their default setting of *USE to *PUBLIC *EXCLUDE.

IBM i NetServer

The IBM i NetServer is what makes IBM i a file server. Two aspects of the NetServer have security implications. The first is that the NetServer can have a guest profile assigned to it. The functionality is as it sounds: when someone connects to the system via a file share, when a guest profile has been assigned to the NetServer, they don’t have to authenticate. They simply map a drive to a file share, and then they have access to whatever the guest profile has authority to access.

Two obvious problems arise from this. First, if multiple people connect as the same user, accountability is lost. Second, if you have not implemented a “deny by default” object security model, users will have whatever the *PUBLIC authority setting happens to be. For example, if the *PUBLIC authority of all database files is *ALL and the root directory has been shared, then every person who has access to your organization’s network can map a drive using the root share, connect without entering a valid IBM i user ID and password, and delete any file on your system!

To review the configuration of the NetServer and the list of users currently connected via a file share, open Navigator for i. Open Network, then Servers, then click on All Tasks. Open IBM i NetServer and choose Properties; when the properties are displayed, choose Security. Figure 7.6 shows that a guest profile—GUESTPROF—has been assigned to the NetServer.

Figure 7.6: Reviewing the NetServer configuration

To remove the guest profile, click Next Start, then blank out the Guest user ID field. Click OK, then stop and restart the server. To review the list of connected sessions, choose Sessions rather than Properties.

To Virus Scan or Not Virus Scan?

Although the IBM i operating system isn’t affected by PC- or UNIX-based viruses and worms, the objects stored in the IFS can be. In addition, the IFS has proven many times that it can very efficiently and effectively store and propagate viruses. Today, most viruses are caught by firewalls, routers, or email scanners and never reach the IFS. However, many organizations have processes that directly place objects into the IFS without passing them through a virus scanner—perhaps a download from a bank, EDI transactions, or FTP from a trading partner. If there’s any opportunity for something to be placed into the IFS without first being virus scanned, you’re putting your system at risk if you don’t scan the IFS. The most effective way to scan the IFS is to use a native virus scanner. I do not recommend that you point a virus scanner engine at the IFS and scan that way. That’s because this method actually creates more vulnerabilities on your system. It requires a read/write share to root (/), and the connection must be established using a profile with *ALLOBJ so that you can be assured all directories are scanned (even those that have been secured), and then, when the scan runs, the entire contents of your IFS are sent over your network in cleartext to the server doing the scan. Not only does this cause excessive network traffic, but all of your information in the IFS is being sent through your network in cleartext. (See why I don’t recommend this method?)

Native-running vendor solutions will use two security-related system values together with exit points to enable both static and real-time virus scanning. These features will allow you to determine when you want files to be scanned.

Tips for Avoiding Malware

Malware can and does affect IBM i. Just because the operating system itself is virus “resistant,” do not be lulled into thinking the system can’t be affected by malware or it can’t happen to your organization. If it never happens, great! But if it does, wouldn’t you rather be prepared? Here are some of the actions you can take to reduce the risk of the system being affected by malware:

• DO NOT SHARE ROOT! There is no need to share root, especially with a read/write share. If you must share root, then make it a read-only share to ensure malware cannot affect objects on IBM i. But it’s better to not share root at all. Why? Because as I mentioned earlier, it shares the entire system, not just the So if someone maps to root, they can see the entire structure of the system. I would prefer not to expose the system in this way. Instead, create shares at the point that needs to be shared, no higher.
• Create shares as read-only whenever possible.
• Hide the share so it cannot be discovered by adding a $ to the end of the name when it’s created, e.g., ShareName$.
• Reduce the permissions on directories to read-only or *EXCLUDE wherever possible to reduce or restrict access.
• Reduce the number of users with *ALLOBJ special authority. An *ALLOBJ user mapped to a file share on IBM i will provide the malware with sufficient authority to do whatever it wants, regardless of the authorities on the That’s also why it’s important to make the shares read-only where possible. Users with *ALLOBJ will still only be able to read the contents when connected to a read-only share.
• Reduce the number of users with *IOSYSCFG special authority. You can create a file share if you have *IOSYSCFG even if you have no authority to the directory being shared.
• If you have exit point software, now’s the time to use it! Put rules in place to restrict who can access the system via the file server exit. (Note: It is not sufficient to simply Rules must be in place to block access.)
• Restrict access to the /QSYS.lib file system when using Windows Explorer (and Navigator for i) by restricting access to (excluding users from) the QPWFSERVER authorization list.

Final Advice

As I said at the beginning of this chapter, the IFS is the most ignored part of IBM i— especially when it comes to security. Now is the time to start addressing security in the IFS. If you do nothing else, follow my guidelines for avoiding malware.

Helpful Tools

The IBM i SECTOOLS menu provides two tools to help you manage authorities to IFS objects. Both the PRTPUBAUT (Print Public Authority) command and the PRTPVTAUT (Print Private Authority) command let you specify a pathname for the object name. When specifying a directory, you also have the option to search the subdirectories and include those objects in the report. Warning: if you run the report for root (/), the printed report for either command can be huge.

Two other commands can be helpful in determining ownership and other object attributes for objects in a directory. The RTVDIRINF (Retrieve Directory Information) command produces an intermediate file of information, which you can then print using the PRTDIRINF (Print Directory Information) command. Unfortunately, the file produced by running RTVDIRINF is in a format that renders the command unusable for running queries or using SQL statements to produce customized reports.

SQL Views

Beginning with V7R4 TR (Technology Refresh) 1 and V7R3 TR7, IBM has provided the following views to help you manage IFS objects, including usage information. This is very helpful when trying to clean up (get rid of) obsolete objects.

• IFS_JOB_INFO
• IFS_OBJECT_LOCK_INFO
• IFS_OBJECT_REFERENCES_INFO
• IFS_OBJECT_STATISTICS