david@elroy.jpl.nasa.gov (David Robinson) (06/27/91)
A question for implementors of NFS clients. How many would break if
the NFS server stopped handling Lookup's of "." and ".."? By handling
it would no longer return "." and ".." on readdir requests and send
back no file errors on lookups?
This would solve the security issues in exporting filesystems. Any reasonable
NFS client already knows the handle of both the current directory and its
parent.
I do recall having to kludge in both "." and ".." for a non-Unix filesystem
in order to make Unix clients happy. In fact early connectathon testsuites
seemed to imply that the server should return "." and ".." entries. Why
force Unix files on the world when unneccesary? I suspect too many things
would break. Something to explicitly specify the the V3 protocol?
-David
--
David Robinson david@elroy.jpl.nasa.gov {decwrl,usc,ames}!elroy!david
Disclaimer: No one listens to me anyway!
"To Protect and Serve and Treat You Like a King" - New LAPD mottokrey@ira.uka.de (Andreas Krey) (06/27/91)
In article <1991Jun26.204047.28889@elroy.jpl.nasa.gov>, david@elroy.jpl.nasa.gov (David Robinson) writes: |> A question for implementors of NFS clients. How many would break if |> the NFS server stopped handling Lookup's of "." and ".."? By handling |> it would no longer return "." and ".." on readdir requests and send |> back no file errors on lookups? |> |> This would solve the security issues in exporting filesystems. Any reasonable |> NFS client already knows the handle of both the current directory and its |> parent. |> Of all the parents down to the root? Otherwise a 'cd ..' would get me to the parent dir, but the client has no way to get at the new parent. Also the parent directory may change when the current dir is moved elsewhere. |> I do recall having to kludge in both "." and ".." for a non-Unix filesystem |> in order to make Unix clients happy. In fact early connectathon testsuites |> seemed to imply that the server should return "." and ".." entries. Why |> force Unix files on the world when unneccesary? I suspect too many things |> would break. Something to explicitly specify the the V3 protocol? |> For my opinion it is unnecessary to explicitly return . and .. entries in READDIR, and the parent directory should be accessed by another operation "handle=getparent(handle)" instead of using LOOKUP with ".." For security/access restriction the server should really look WHO is doing the LOOKUP("..") and return error if the export point is crossed. Some NFS servers don't look on the 'who' field at all except for getting the return address. |> -David |> -- |> David Robinson david@elroy.jpl.nasa.gov {decwrl,usc,ames}!elroy!david |> Disclaimer: No one listens to me anyway! |> "To Protect and Serve and Treat You Like a King" - New LAPD motto -- Andy ...signature: No such object
rbraun@spdcc.COM (Rich Braun) (06/29/91)
david@elroy.jpl.nasa.gov (David Robinson) writes: >A question for implementors of NFS clients. How many would break if >the NFS server stopped handling Lookup's of "." and ".."? >... >I do recall having to kludge in both "." and ".." for a non-Unix filesystem >in order to make Unix clients happy. In fact early connectathon testsuites >seemed to imply that the server should return "." and ".." entries. Why >force Unix files on the world when unneccesary? I think the implementers of NFS originally tried to avoid this requirement but didn't quite get it right; the parent file handle (inode) is handed back to the client on every file lookup, so there *shouldn't* be a need for "." and "..". But these files were passed across in READDIR func- tions, and I'll bet a lot of client implementations just took advantage of this fact rather than acknowledging that "." and ".." are Unix-specific constructs. For the SOSS server, with which I'm most familiar, I solved the problem of exporting a subdirectory of a filesystem by lying to the client about the parent inode of that particular subdirectory. For example, if I export /c/foo, then I tell the client that "." and ".." both have the inode number of directory C:\FOO. But there's a catch: if I export two "filesystems", one of which is lower in the tree than the other (example: /c and /c/foo), then a user traversing from the higher-level filesystem down into the lower-level one will become confused when he tries to go back up (e.g., cd /c, then cd /c/foo/bar, then cd ../.. will go to directory /c/foo rather than /c). Foo, I think I've just confused a lot of netnews readers too! ;-) Anyway, I think this is the reason why Unix NFS implementations don't let you export a subdirectory of a filesystem. But there's nothing in the protocol itself to prevent you from doing that, as SOSS demonstrates. -rich