Path: utzoo!attcan!uunet!husc6!cmcl2!nrl-cmf!ames!haven!purdue!decwrl!sun!aeras!elxsi!beatnix!mre
From: mre@beatnix.UUCP (Mike Eisler)
Newsgroups: comp.protocols.nfs
Subject: Re: Yes, Virginia, you *can* have UNIX filenames containing '/'
Message-ID: <1162@elxsi.UUCP>
Date: 21 Nov 88 19:31:19 GMT
References: <5945@fluke.COM> <10176@swan.ulowell.edu>
Sender: news@elxsi.UUCP
Reply-To: mre@beatnix.UUCP (Mike Eisler)
Organization: ELXSI Super Computers, San Jose
Lines: 55

In article <10176@swan.ulowell.edu> arosen@hawk.ulowell.edu (MFHorn) writes:

>So how does the server create such a file?
>
>The server has to ask the kernel (via syscalls, like everyone else)
>to create the file for it.  The kernel parses every filename it's
>given through the magic of lookupname().  That's why you can just
>say open("/foo", O_RDWR), instead of open(devnum, inum, O_RDWR).

No, the server doesn't have to "ask" the kernel anything, because the
NFS server implementation in SunOS is in the kernel, and relies on
Sun's vnoded Virtual File System architecture. When the server receives
a packet from a client, it invariably contains a file handle that the
server converts to a vnode pointer. The server can then execute the
requested operations on the file (or directory) in a file system
independent manner, because each vnode contains a pointer to a vector
of file system dependent operations (sort of like how the character and
block device driver switches, cdevsw[], and bdevsw[], permit UNIX to
transparently access devices as files).

When a request comes in to create a file, the server receives the file
handle of the new file's parent directory, and the name of the file,
within the directory. The server converts the directory file handle to
a vnode, and invokes the operation that is used to create files on the
directory's file system type.  Evidently, in the current version of
SunOS, the file creation operation for the local file system type
("ufs_"), no check is made for files containing bad characters like
"/".

I suspect the check is missing because before NFS came along, all file
creation requests had to go through namei(). Namei() did all the work
of checking for good file names, and of course when it encountered "/",
treated in as a directory component name separater.  The vnoded SunOS
has lookupname() to do the job of namei(), but path of file creations
from the network directly to the file system was overlooked.

>In the above case, the kernel would get open("//./..///", O_RDWR|O_CREAT),
>or something similar, try to open "/" for write and fail with EISDIR.

Of course, some NFS servers are not kernel resident, and are just file
servers that support the NFS protocol. So, in this case, the NFS server
would indeed have to "ask" the kernel to create a file, and so a file
name with a "/" in it would be impossible.

>It's possible that the RPC system calls are stupid (ie. they don't
>use lookupname); I've never seen kernel code for RPCs.  If so, then
>this is where the bug is, not in the server code.

RPC's, at least under SunOS, are neither implemented as system calls,
nor have any knowledge of the information they are sending and receiving.
For applications there is set of rpc routines bundled in libc.a. For the
in kernel NFS server and client, there a set of differnet rpc routines
bundled in the kernel.
	-Mike Eisler
	{sun,uunet}!elxsi!mre