Tux Knows It's Nice to Share, Part 2
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:
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.
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.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Peppermint 7 Released
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Sony Settles in Linux Battle
- Libarchive Security Flaw Discovered
- Maru OS Brings Debian to Your Phone
- Understanding Ceph and Its Place in the Market
- Profiles and RC Files
- Snappy Moves to New Platforms
- Git 2.9 Released
- The Giant Zero, Part 0.x
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide