files with /

[William E. Davidsen Jr]

Some time ago I posted a question about getting rid of names with / in
them, and many people assurred me that it couldn't happen (I had the
problem, so it does). Here are some comments on the topic from another
group, indicating that other people have this problem, too.

I don't intend to start a rehash of the topic, just wanted to share
these with people for informational value.
________________________________________________________________

From: jeff at tc.fluke.COM (Jeff Stearns)
Newsgroups: comp.protocols.nfs
Subject: Yes, Virginia, you *can* have UNIX filenames containing '/'
Date: 11 Nov 88 18:50:23 GMT


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 at 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.
________________________________________________________________

From: guy at auspex.UUCP (Guy Harris)
Subject: Re: Yes, Virginia, you *can* have UNIX filenames containing '/'
Date: 12 Nov 88 07:09:57 GMT


>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).
________________________________________________________________

From: arosen at hawk.ulowell.edu (MFHorn)
Subject: Re: Yes, Virginia, you *can* have UNIX filenames containing '/'
Date: 12 Nov 88 19:26:29 GMT


>From article <5945 at fluke.COM>, by jeff at 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 at 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

-- 
	bill davidsen		(wedu at ge-crd.arpa)
  {uunet | philabs}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me