jeff@tc.fluke.COM (Jeff Stearns) (11/12/88)
Most of us think of '/' as a separator in Unix pathnames, but it ain't
always so. I just created several files with '/' in the filenames
themselves.
It's remarkably easy to do - just cook up an NFS packet with the
appropriate bits in it. NFS servers don't care; they're not responsible
for parsing pathnames, so they don't know about separators. They deal
only in individual filenames. If an NFS client wants to name a file
"//./..///", that's fine with the server. Into the directory it goes.
Makes for some fun later when UNIX tries to do anything with the file.
As you can imagine, most system calls will fail.
This isn't really a bug so much as a consequence of the fact that the NFS
spec isn't specific to UNIX semantics. From the NFS point of view, such
files should be allowed.
It does raise some interesting questions about the limitations of
heterogeneous systems. And it's one of the few times when UNIX chokes on
a filename which is legal on other operating systems (my example actually
comes from a Macintosh speaking to the NFS via a Cayman GatorBox).
--
Jeff Stearns John Fluke Mfg. Co, Inc. (206) 356-5064
jeff@tc.fluke.COM {uw-beaver,microsoft,sun}!fluke!jeff
PS - Calling all users of the Vitalink TransLAN IV Ethernet bridge! Please
drop me a line.guy@auspex.UUCP (Guy Harris) (11/12/88)
>This isn't really a bug so much as a consequence of the fact that the NFS >spec isn't specific to UNIX semantics. From the NFS point of view, such >files should be allowed. I'd call it a bug in the UNIX NFS server code as distributed by Sun; it's serving up a UNIX file system, and file names (component names) containing "/" are illegal under UNIX. (In fact, I think it *did* call it that, filing a bug report against it....) Since you can't "rm" such files from UNIX, it's kind of impolite of the server to let them through. Such files should be allowed if the server is willing to allow them, but servers aren't obliged to allow them (you could write an NFS server for a file system that allowed only 26 files named "A" through "Z" if you want).
arosen@hawk.ulowell.edu (MFHorn) (11/13/88)
From article <5945@fluke.COM>, by jeff@tc.fluke.COM (Jeff Stearns): > Most of us think of '/' as a separator in Unix pathnames, but it ain't > always so. I just created several files with '/' in the filenames > themselves. > > It's remarkably easy to do - just cook up an NFS packet with the > appropriate bits in it. NFS servers don't care; they're not responsible > for parsing pathnames, so they don't know about separators. They deal > only in individual filenames. If an NFS client wants to name a file > "//./..///", that's fine with the server. Into the directory it goes. 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). 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. 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. Andy Rosen | arosen@hawk.ulowell.edu | "I got this guitar and I ULowell, Box #3031 | ulowell!arosen | learned how to make it Lowell, Ma 01854 | | talk" -Thunder Road RD in '88 - The way it should've been
guy@auspex.UUCP (Guy Harris) (11/15/88)
>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. Uhh, no, it doesn't. It has to ask the underlying *file system* to create the file for it; the server is *part* of the kernel, at least in the Sun implementation. NFS requests don't contain pathnames, they contain component names. Thus, the NFS server passes the pathname a component at a time to the file system; the components can contain '/'. >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. I fail to see why it is *ipso facto* "stupid" not to use "lookupname". They aren't "RPC system calls"; for one thing, it's NFS, not RPC (you can implement things that aren't system calls with RPC), and for another, NFS calls don't have to correspond directly to system calls. Either 1) the code in the file system implementation or 2) the code in the NFS server should check for "/".
mre@beatnix.UUCP (Mike Eisler) (11/22/88)
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
cs@kanawha.Sun.COM (Carl Smith) (12/09/88)
Of course NFS allows file names containing `/'. It isn't up to NFS to enforce the pathname restrictions of underlying file systems. There are systems in which '/' is a perfectly legal character to include in a file name. It is, however, a bug that the underlying UFS implementation doesn't check for it. Carl
brad@cayman.COM (Brad Parker) (12/12/88)
From article <80716@sun.uucp>, by cs@kanawha.Sun.COM (Carl Smith): > > Of course NFS allows file names containing `/'. It isn't up to NFS > to enforce the pathname restrictions of underlying file systems. But it would be nice if NFS had some mechanism for telling clients what the restrictions are. ;-( -- Brad Parker Cayman Systems, Inc. Cambridge, Ma. brad@cayman.com
cs@kanawha.Sun.COM (Carl Smith) (12/13/88)
> But it would be nice if NFS had some mechanism for telling clients what > the restrictions are. ;-( There is a provision for doing this in version 3 of the protocol. The NFSPROC_GETFSINFO procedure returns, among other things, a list of characters not allowed in a file name. > The email address for sending comments on the next > protocol (version 3), is sun!cs, or cs@sun.com. The correct address is actually sun!nfs3, or nfs3@sun.com. Carl