davidsen@steinmetz.ge.com (William E. Davidsen Jr) (11/15/88)
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@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@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@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@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@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
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -memike@turing.unm.edu (Michael I. Bushnell) (11/15/88)
In article <12589@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: >So how does the server create such a file? [a file with '/' in the name] >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). Except that in the standard NFS implementation, the server IS the kernel. The server interacts with the filesystem below the pathname traslation level. >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. Except that the kernel doesn't have to talk to itself through the syscall interface, and so it can bypass these sort of restrictions. Look at the code: it actually *is* cleaner the way it is done. It's just that the clean semantics lead to an ugly bug. >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. Except that, once again, the kernel code IS the server. >-- > bill davidsen (wedu@ge-crd.arpa) > {uunet | philabs}!steinmetz!crdos1!davidsen >"Stupidity, like virtue, is its own reward" -me Indeed. N u m q u a m G l o r i a D e o \ Michael I. Bushnell \ HASA - "A" division /\ mike@turing.unm.edu / \ {ucbvax,gatech}!unmvax!turing.unm.edu!mike
peter@ficc.uu.net (Peter da Silva) (11/17/88)
Perhaps namei should pass the remainder of the file name verbatim to the remote site once it hits a remote mount point. I realise that this could cause some file naming nightmares, such as... /vax/_DRA0:[user.directories]fred.com;37 /unisys/project*source(-1).fred/for Perhaps allowing homogenous mount points (namei keeps stepping through the file name over the net) and hetrogenous ones (namei throws its hands in the air and lets the guy at the other end take charge) would help: /vax/user/directories/fred.com /rvax/_DRA0:[user.directories]fred.com;37 -- Peter da Silva `-_-' Ferranti International Controls Corporation "Have you hugged U your wolf today?" uunet.uu.net!ficc!peter Disclaimer: My typos are my own damn business. peter@ficc.uu.net