On Mon, Nov 22, 2004 at 06:05:43PM -0800, Martin Buchholz wrote: > I mean, > - first go back to the parent directory > - then lstat("foo"); check if it's a symlink or a real directory > - if a symlink, then this is fishy, but it could happen non-maliciously. > I would issue a warning, then continue, without chdir'ing into foo. > - if a directory, then probably we've hit the automounter problem. > Don't issue a warning; chdir("foo") again; this time it should work. It sounds like this strategy, which is the same as we currently do, but with a retry, is fairly sensible. The only problem that occurs to me is that we did not recheck "foo" to see if it still matches the predictes specified on the find command line (think about commands like find /z -user fred -o -name baz -print ... here, if the original "foo" was owned by root but the "new" foo is owned by fred, our retrying technique has ensured that we have wandered into a place which we are not supposed to. It's possible that we could simply reissue process_path() to retry instead of directly trying the chdir("foo") again. I can't remember offhand if that is likely to be a viable strategy. > Unlike replacing directories with symlinks, where the malicious > possibilities are evident, I don't see any malicious possibilities > arising out of mounted filesystems replaced by other filesystems. Is there a consensus agreeing with this point of view? If so, that would make the implementsation much simpler... > Hmmm... You're right. I guess you'd have to: > FD=open("foo"); > ST1=lstat("foo"); I think find would have to use xstat() there because "-L" ("-follow") might be in effect, problematic though it is security-wise. xstat in GNU find is a function pointer that points to lstat() if the -P flag is in effect (this is the default; the explicit -P is a BSD invention), points to stat() if the -L flag is in effect, and points to a more complex function optionh_stat() if -H is in effect (optionh_stat() eventually calls either stat() or lstat()). > ST2=fstat(FD); > compare(ST1,ST2); > fchdir(FD); I wonder what happens there if we're at an automount mount point. Does the fchdir() provoke automount() into mounting the filesystem? Would you be able to check this, Martin? > On a related note, > Solaris has some interesting non-standard functions: > > int openat(int fildes, const char *path, int oflag, /* > mode_t mode */...); > > The openat() function is identical to the open() function > except that the path argument is interpreted relative to the > starting point implied by the fd argument. If the fd argu- > ment has the special value AT_FDCWD, a relative path argu- > ment will be resolved relative to the current working direc- > tory. If the path argument is absolute, the fd argument is > ignored. So, with an absolute path or with AT_FDCWD, it's equivalent to open(2)? If'a a shame that openat() doesn't have a flag to prevent it following symbolic links. Or does it?