BugTraq
Changes to the filesystem while find is running - comments? Nov 22 2004 10:27AM
James Youngman (bugtraq excession spiral-arm org) (1 replies)
Re: Changes to the filesystem while find is running - comments? Nov 22 2004 06:05PM
Martin Buchholz (Martin Buchholz Sun COM) (2 replies)
Re: Changes to the filesystem while find is running - comments? Nov 22 2004 11:51PM
James Youngman (bugtraq excession spiral-arm org) (3 replies)
Re: Changes to the filesystem while find is running - comments? Nov 24 2004 07:51AM
Casper Dik Sun COM (2 replies)
Re: Changes to the filesystem while find is running - comments? Nov 24 2004 05:25PM
Martin Buchholz (Martin Buchholz Sun COM) (1 replies)
Re: Changes to the filesystem while find is running - comments? Nov 24 2004 12:15PM
James Youngman (bugtraq excession spiral-arm org)
Re: Changes to the filesystem while find is running - comments? Nov 24 2004 05:24AM
devnull Rodents Montreal QC CA
Re: Changes to the filesystem while find is running - comments? Nov 23 2004 02:05AM
Martin Buchholz (Martin Buchholz Sun COM) (1 replies)
Re: Changes to the filesystem while find is running - comments? Nov 23 2004 09:17AM
James Youngman (bugtraq excession spiral-arm org) (1 replies)
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?

[ reply ]
Re: Changes to the filesystem while find is running - comments? Nov 23 2004 05:59PM
Martin Buchholz (Martin Buchholz Sun COM)
Re: Changes to the filesystem while find is running - comments? Nov 22 2004 06:33PM
Dmitry V. Levin (ldv altlinux org)


 

Privacy Statement
Copyright 2010, SecurityFocus