Whoa! What a segueway. This can only mean that we have reconvened for yet another installment of the "SysAdmin's Corner". As you might remember, we were last discussing NFS file sharing. I called it the Gread-Grand-Somethingorother of network file sharing. Then, we looked at basic setup and exporting file systems to be mounted on remote systems. The basic format of the /etc/exports file looks something like this:

     /name_of_dir    client_name(permissions)

In particular, I used an example where I exported my own /mnt/data1 directory with these options:

     /mnt/data1         192.168.1.2(rw,no_root_squash)

In other words, allow the computer at 192.168.1.2 to mount this directory wherever it wants and, then, allow read and write permissions even as root. The default, as I mentioned, is to treat root as an anonymous user, thus severely limiting its access. This is where I want to pick up today: Security in the world of NFS. In the above example, I am assuming that I, being the system administrator, am the one with root access to all machines. I trust myself. Trust, however, must be meted out carefully.

After the last column came out, one reader asked (in the nice little comment form at the end of the article) whether you could have the home directory exported so a user would have access to the same desktop, e-mail or data, no matter what workstation he or she logged in from. The answer to my anonymous reader's question is "yes". This is a very common use for NFS. Answering this question fully, however, means that we should consider permissions in somewhat more detail than in the last column. Unfortunately, permissions is where NFS becomes quite tricky.

Options for the permissions (or security) section are secure, ro, rw, sync, no_wdelay, nohide and no_subtree_check. Another group of permissions exist related to the way individual users are treated. I like to think of these as the squashing permissions for reasons you will soon see when I name them. Of course, this is just me, and I have been known to express things in (how shall I put this?) my own special way. These squashing permissions are root_squash, no_root_squash, all_squash, anonuid and anongid.

Okay...some detail; secure means that an NFS mount request must be from an internet port number below 1024. That's the default. If you don't want this, then specify insecure.

Next, we have ro or rw. If you choose ro, then an exported directory is set for read only access. Since this is the default, you must specify rw to allow read and write access. Moving on to our next permission option, sync, we have what you might call a mixed blessing. What it does is make sure that a commit of data follows every write operation. This is great in the event of your server going kaboom, but the cost is a slight performance hit. The default, by the way, is async which means that the system just writes and doesn't worry about whether the operation completed before moving on. Cousin to the sync option is no_wdelay, our next contestant. If you decide that your data is relatively safe (but you still want the commit option), you can override the default, wdelay, and elect to set this option which lets the system do multiple commits simultaneously rather than delaying the next write until the first is committed.

Say you have two directories exported in the same tree. If one of those directories is below the first, it makes sense that you would normally mount both on the client. If you only mounted the parent directory, you would see the second directory but with no data beneath it. It is hidden, right? Now, if you want to have the entire sub-tree visible as well, use the no_hide option. Use it with care, however, since the clients have been known to have strange duplicate inode problems with this one. As you might have guessed, the default option is to hide. In the same vein, we have the last non-squashing permission, no_subtree_check. This is another one related to subdirectories. If the directory you are exporting is actually a subdirectory of a file system, then the directories above may have something to say about permissions. Since you only have access to the files and directories which are exported, checking must be done to ensure security throughout the chain. The default is to allow subtree_check which may have minor security implications. If this is a concern, remember to specify no_subtree_check.

And now, the long-promised squashing permissions. Generally, these have to do with how the server deals with the problem of user ids (UIDs) and group ids (GIDs) while assigning permissions; this is where NFS often confuses the <insert appropriate expletive here> out of people. The thing to remember here is that NFS, in a default installation, deals with permissions by assuming that UIDs and GIDs are the same on both the server and the client. This isn't such a big deal if you are the one setting up all the machines, defining the rules and making sure all machines have identical /etc/passwd files. Unfortunately, this isn't always the case. The real problem starts when user "natika" on the server has UID 505, but "natika" on the client has UID 501.

One way to deal with this is to run something called "NIS", which stands for Network Information Service. We'll cover setting up an NIS server in a later column. Another way is to change the default behavior of NFS when a mount request is honored. Remember my no_root_squash mount example earlier on? Here it is again.

     /mnt/data1         192.168.1.2(rw,no_root_squash)

When a user tries to gain access to a remote NFS directory, the UID and GID are treated as though they are the same on the client and server UNLESS you are root. NFS maps root's UID (0) to the anonymous user, or "nobody" for security reasons. This is the default root_squash option. If you are the administrator of the NFS domain and root on all machines, this might not be a problem, and you may want root to have equal rights to the exported directories. You can also do an all_squash and override the default no_all_squash which, as you might expect, means all UIDs should be treated like root, mapping them to the anonymous user. Finally, if you want to specify this mysterious anonymous user, use either anonuid or anongid, or both. This allows you to specify the UID and GID of the anonymous user to which a root_squash or an all_squash will map permissions.

Have a look at the following example.

     # /etc/exports file
     # These are just comments
     #
     /mnt/data1              natika(rw,no_root_squash)
     /usr/local              speedy(rw)
     /mnt/acctng             *.mycompany.com(rw)

The first three lines (starting with the "#" symbol) are just comments. The /mnt/data1 line would make that directory available to the client called "natika". It would also allow root to be treated as root on this directory. The second line allows the client called "speedy" read-write access, but maps root's UID to the anonymous user. Finally, the third line allows any computer in the "mycompany.com" domain to mount the /mnt/acctng directory with read-write access.

Now that we have all these permissions set and all our exports taken care of, how does a person on a remote system know what directories are available for mounting (short of asking you specifically)? Using the showmount command, we can find out what directories any given server has exported, like so

     [mgagne@testsys mgagne]$ /usr/sbin/showmount --exports 192.168.22.2
     Export list for 192.168.22.2:
     /data1     192.168.22.100
     /mnt/cdrom 192.168.22.100 

Notice that the permission information is not displayed.

Yes, there is more, but I have filled my alloted space yet again. In future columns, I want to talk about the different incarnations of NFS, how you can change and even automate remote directory access, and lots more. So, it is here that I leave you. Until next time, remember what your Momma said, "It's nice to share".

Looking for past articles to this series? Click here for a list.