bug-findutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fwd: [bug #17877] Invalid "No such file or directory" error on files


From: James Youngman
Subject: Re: Fwd: [bug #17877] Invalid "No such file or directory" error on filesystem without stable inode numbers
Date: Thu, 5 Oct 2006 16:21:56 +0100

[+bug-findutils since we're discussing this example in that context]

On 10/5/06, Miklos Szeredi <address@hidden> wrote:
> But what about symlinks?
>
>   a       g
>    b       h->a
>     c
>      f->g
>
> The moment you traverse the f->g symlink above,
> the entire tree, a/b/c/f, is no longer referenced,
> so the h->a link may take you back to a new inode,
> and the cycle will not be detected.

Right.  So find either holds a file descriptor for each symlink
traversed,

But at the time we traverse the symlink, we don't know it's a symlink.
 Here's the order of events:

process 1 stats "." and remembers the resulting device and inode.
process 1 stats c.   It is told that c is a directory, not a symlink.
process 1 chdirs into c.  Now, CWD=/a/b/c, and that's where it thinks it is.
process 1 stats ".." and compares the device and inode with the previous value.
 - these are the same so the security check succeeds.
process 1 stats d.  It is told that d is a directory, not a symlink.
process 2 renames d to d~, and creates a symlink d pointing at /g/h
process 1 chdirs into d.  Now CWD=/g/h but it thinks this is /a/b/c/d
process 1 stats ".." and compares the device and inode with the previous value.
 - these are DIFFERENT so the security check FAILS.  (as we would want)

So here, We stat ".." with CWD="/g/h" to determine that it is
different to "/a/b/c".

(this logic is taken from oldfind, I'm much less sure how fts tackels
the same situation)

or just ignore this problems for inode-less filesystems

I'm very reluctant to do that.   It's the rare problems that the
quality tools should worry about.  Common problem the user normally
knows about and can cope with.

(find -L is relatively rarely used).

It doesn't really matter that the feature is rarely used.  Security
problems are bad, even if they only exist in rarely-used program
features.

I agree that compromises are unavoidable.

I guess the problem doesn't arise for SMBFS, since there are no
symlinks available.    Hence ofr the SMBFS case, one workaround could
be to just skip the check, but there's no easy way to tel that it is
safe to do that.

The problem is arguably worse for SSHFS, because SFTP doesn't support
"ls -i" anyway, whereas the underlying filesystem could be susceptible
to the kinds of attacks we're talking about.

However the bug I originally reported was not a theoretical one, it
was reported for a _real_ FUSE filesystem used on gentoo (which
carries find-4.3) and very likely will be reported for
smbfs/cifs/fat/etc sooner or later.

Well the problem is more or less similar to the difficilties of NFSv3
servers with NFSv2 clients, or 32-bit clients on systems where st_ino
is 64 bits (for example HPUX 11i has this property, I think).

James.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]