nowicki@SUN.COM (Bill Nowicki) (12/23/86)
Development of real commercial network protocols is full of compromises, so it is not too suprising that some people think NFS is too Unix-like, while others think it is not Unix-like enough. Commercial MS-DOS and VMS products were demonstrated in February 1986, as well as many different Unix dialects, from PCs to a Cray-2. Let me try to correct some misconceptions: ..., NFS has no security or authentication. Authentication is done at the RPC level in a very open-ended manner. The default in the first implementation was to trust UIDs, since that is all that Unix provides. A scheme based on public-key encription has been discussed in papers (Goldberg and Taylor, Usenix conference 1985). ... it is assumed that there is a GLOBAL /etc/passwd file No, your implementation is free to have a simple table that maps these UIDs into whatever identifier that you use on your system. We found it easier to administer by keeping a unique number over as large a domain as possible. At some point you may have to translate between numbers that make sense in your domain, but having N x M translation tables is not practical to maintain. NFS uses very large UDP packets ... No, details of transport such as packet size are determined by both the client and server implementations. Slow machines like PCs use small transfer sizes, while faster machines such as Sun-3s take advantage of larger buffer sizes when available. So if a complete RPC and NFS can be fit into 64K, why is PC-NFS client only? Although I am not a PC user (luckily I have a Sun-3/75) my understanding is that MS-DOS (and the Mac, for that matter) can only run one program at a time. Therefore if you ran a server, then you could not run any other programs on that PC. We find in actual practice that people only put on floppies the files that they DO NOT want other people to get at - shared files can go on an NFS file system, and you use MS-DOS "COPY" commands to copy from one PC to another. Remember that Sun is an active member of the Corporation for Open Systems, and has ISO and FTAM (second DP version) products. NFS only makes many of the file-sharing problems visible - we need to continue research in this area. On the other hand, people with inter-operability questions should come to Uniforum in January 1987 and see it work for themselves. -- Bill Nowicki Sun Microsystems Above are personal opinions only, not official Sun positions.
mark@cbosgd.mis.oh.att.com.UUCP (12/25/86)
In all this discussion of ways that NFS doesn't quite meet the "UNIX semantics" (this means "UNIX System V semantics", since UNIX is a trademark of AT&T and AT&T considers only its own releases to be UNIX) there is one more gotcha lurking. ANSI X3J11 C has a required function called tmpfile(). This function takes no arguments, and is defined in the 10/86 draft section 4.9.4.3 thus: Synopsis #include <stdio.h> FILE *tmpfile(void); Description The tmpfile function creates a temporary binary file that will automatically be removed when it is closed or at program termination. The file is opened for update. Returns The tmpfile function returns a pointer to the stream of the file that is created. If the file cannot be created, the tmpfile function returns a null pointer. The traditional implementation of this function is to make up a name in /tmp, create the file, keep it open, and unlink it. This works fine on System V and 4BSD. It probably fails on VMS/Eunice. As far as I'm aware, it also fails when /tmp is NFS mounted on a remote system. Given the stateless nature of NFS, is there a way to upgrade it to support tmpfile? If not, it's going to be awfully hard to conform to ANSI C in an NFS environment. Mark Horton
jqj@GVAX.CS.CORNELL.EDU.UUCP (12/28/86)
In article <4889@cornell.UUCP> nowicki@Sun.COM (Bill Nowicki) writes: >Let me try to correct some misconceptions: > ..., NFS has no security or authentication. >Authentication is done at the RPC level in a very open-ended >manner. The default in the first implementation was to trust UIDs, >since that is all that Unix provides. A scheme based on public-key >encription has been discussed in papers (Goldberg and Taylor, Usenix >conference 1985). Although Bill is technically correct, it still seems fair to say that "NFS has no security or authentication" and that this is a VERY serious weakness of the SUN NFS standard. SUN RPC is open ended in this regard, but the only form of authentication standardized is "UNIX-style" i.e. none. Since SMI has not officially endorsed the Goldberg&Taylor scheme, the situation is far worse than a simple lack of implementation. The fact remains that one can easily break security on any SUN NFS cluster if he/she has access to any diskless client. More abstractly, it is arguable that authentication at the RPC level is inappropriate for application-level security. It requires that the application (NFS) have a much closer coupling than I would like to the transport mechanism (RPC). As an example of the problems that this confusion of layering causes, consider how you'd handle a file system type that required secondary authentication, e.g. a Tops-20 like system that had both user id's and file "accounts", with perhaps a password associated with the account -- seems to me your NFS-level authentication scheme must of necessity be specific to the particular type of remote file system if you want file security equal to what you have in a local file system. For comparison, consider Authentication in the Xerox Filing (distributed file system) protocol, which is much more robust than anything I've seen considered as an NFS extension (but which still has major flaws...). See "Authentication Protocol", XSIS 098404, and "Filing Protocol", XNSS 108605.
tim@cgl.ucsf.edu@hoptoad.UUCP (01/04/87)
Two comments on PC NFS.
A server side is not made impossible by the OS lack of support for
process-based multi-tasking. If TOPS is any indication, acceptable
performance is possible with a background server design.
Second, floppies were mentioned. Floppies are irrelevant. The average
MS/DOS machine these days has a ten or twenty megabyte internal hard disk,
parts of which might often be made public.
--
Tim Maroney, Electronic Village Idiot
{ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp)
hoptoad!tim@lll-crg (arpa)