Security

NFS servers currently control access to their files using "trusted host" security. The server trusts that the client machines will construct a valid credential that correctly identifies the individual requesting file access. Generally the server identifies the list of trusted client machines with an access list that explicitly lists the names of the client machines, or identifies a "netgroup" that lists the names of trusted clients or other netgroups. If the client machine is "trusted" by the server then the NFS client will be able to access the server like any other NFS client.

Since the Java Runtime has no concept of the user's identity the NFS client cannot automatically construct a credential that identifies the user with a UID or GID value since these values may be meaningless on platforms that do not support them (Macintosh and Windows machines do not require the user to log in). Instead, the client constructs a "nobody" credential that uses a UID and GID value of 60001 which the server identifies as user "nobody". Since file access permissions on public or Internet archive servers are often liberal in allowing read access to anyone, the "nobody" identity is of no consequence. However, if the user wishes to access private files in his or her own home directory or to create files with his or her identity assigned to the owner of the file then a credential with the user's UID and GID must be used.

The NFS client uses the same technique to acquire a valid user credential as PC-NFS clients - it uses the network PCNFSD service. The PCNFSD service is commonly installed wherever PC-NFS clients are present. It need not be installed on every NFS server, only one server in the network is sufficient. The NFS client provides a loginPCNFSD() method in that can be called through the NFS XFileExtensionAccessor class. This method takes the user's login name, password and the name of a host running the PCNFSD service and passes this information to the PCNFSD server (the password is not encrypted but it is obscured by exclusive ORing with a bit pattern so that the password is not disclosed to casual network sniffers). If the login name and password are valid the PCNFSD server returns the user's UID and GID which the NFS classes then use in subsequent requests to the NFS server. Here is an example of the a Java application setting the user's credential:

                import sun.xfile.*;
                import sun.nfs.*;

                public class pcnfsd {

                    public static void main(String av[])
                    {
                        try {
                            XFile xf = new XFile(av[0]);

                           nfsXFileExtensionAccessor nfsx =
                                (nfsXFileExtensionAccessor) xf.getExtensionAccessor();

                            if (! nfsx.loginPCNFSD("pcnfsdsrv", "jane", "-passwd-")) {
                                System.out.println("login failed");
                                return;
                            }

                            if (xf.canRead())
                                System.out.println("Read permission OK");
                            else
                                System.out.println("No Read permission");

                        } catch (Exception e) {
                            System.out.println(e);
                        }
                    }
                }

Of course a more realistic application would likely obtain the parameters for the call to loginPCNFSD() from a dialog box with a protected text field for the user's password.

The "trusted host" security has several shortcomings, not the least of which is that it is not particularly secure. A determined network sniffer could monitor PCNFSD calls and obtain passwords, a malicious client could masquerade as a "trusted" host by spoofing the source IP address, or the trusted host itself could be compromised in which case an intruder could spoof the credential of anyone. In addition, on an Internet scale it would be impractical to maintain access lists for all client machines. Even then, it is common for users to access the server from unpredictable IP addresses either because the client is a "kiosk" machine used by many different users, or because the source IP address is dynamically allocated by a DHCP server.

For this reason there is work underway in the IETF to define more secure NFS authentication. The secure RPC working group has devised a new framework for secure RPC called "RPCSEC_GSS" ( RFC 2203 ) which is based on the IETF's GSS-API, an open-ended framework that facilitates "plug-in" security schemes that can provide secure authentication, data integrity and data privacy for NFS traffic on the network. SunSoft(TM) is currently working on a Solaris plug-in for Kerberos v5 which will also be available in a future delivery. The RPCSEC_GSS mechanism will also support public key based security schemes that are more suitable for Internet use.