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: Miklos Szeredi
Subject: Re: Fwd: [bug #17877] Invalid "No such file or directory" error on filesystem without stable inode numbers
Date: Thu, 05 Oct 2006 20:28:41 +0200

> > > 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.

The worst that can happen is that the security check makes a false
alarm.  That in no way makes the security weaker.

> > 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).

And no wonder they are similar, since in both cases the root of the
problem is how to map a large ID space into a small one.

Miklos




reply via email to

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