Re: [bug #17877] Invalid "No such file or directory" error on filesystem without stable inode numbers

[Miklos Szeredi]

> > > There must already be such problems with hard links anyway, so this
> > > extra problem isn't that much worse.
> >
> > Yes it is.  Neither sftp, nor smbfs, nor fat support hard links.  All
> > of them support rename.
> 
> Not entiirely accurate.   SSHFS supports whatever the underlying
> remote filesystem supports.  That might include hard links.  That is,
> directories A and B visible under SSHS could both be symbolic links to
> some other directory.  Files C and D could be hard links to the same
> inode.  However, the ls command of SFTP does not have any kind of "-i"
> option and so it is impossible to discover that this is the case.

Yes, under sshfs a hard linked file would look like two different
files, that just happen to be magically synchornized.  There's nothing
wrong with this from the POSIX POV.

> > What about embedded devices, where the table would not fit in memory?
> > My guess is that an entry in such a table would be minimum 32bytes.  A
> > million such entries would take 32Mbytes.
> 
> Not sure what you're suggesting here.   You clearly wouldn't be
> suggesting that everybody's interpretation of struct stat.st_ino
> should change just because of potential implementation limitation of a
> wristwatch-based Linux system.  So I'm not sure what you *are*
> suggesting here.

You don't even want sshfs to permanently (until unmount) use 32Mbytes
on your desktop system, just because you did a 'find' on a filesystem
with a million nodes.  OK, firefox is worse than that, but still ;)

And there are filesystems with not a million but hundreds of millions
of nodes.  The point is, just permanently storing the mapping is not
the solution.

I'm not against an option for fuse, that tells it the number of inodes
to cache.  Then paranoid people can set it to a million or whatever.
That's OK, but it still does not generally solve the problem.

> Clearly using a hash function to supply inode numbers from path names
> would not reqiure you to store an in-memory hash table.   The hash
> value is enough.

No, because if you rename a file, the inode number and the path name
hash will no longer match.

> > > Again, it is unreasonable to expect standard utilities to port around
> > > file systems that don't have reliable inode numbers.  It breaks too
> > > many other things: simplicity and security being the most important
> > > two.
> >
> > It breaks neither of those.  You are clearly just making this up,
> > without understanding the issues.  If you are actually interested in
> > what's involved in fixing an application please follow the discussion
> > on gnulib-bugs.
> 
> Let's move a little towards a position where we can make progress.  As
> to how findutils might change,
> 
> 0. Changes to make find functinally incorrect (i.e. give the wrong
> answer ans return qith exit status 0) will not be (deliberately) made
> 1. Changes to find which reduce its level of security will only be
> accepted if this is necessary to correct functional defects
> 2. I'm basically not willing to make changes to fix (even functional)
> problems on accessory filesystems if this reduces the level of
> security of the program on 'core' filesystems.   (The distinction here
> is between for example the filesystem that / or /home is on and other
> stuff like AFS).
> 3. Code changes must follow the GNU coding standards (including
> copyright assignments, as the FSF requires).
> 4. I prefer changes which include documentation, and, normally, prefer
> changes that are small rather than changes that are big.

All of these sound perfectly reasonable.  Jim Meyering said, he has a
patch under testing.  Hopefully that will resolve this issue with fts
and find.  As I've said I'm not worried about other utilities, which
only rely on stable inodes for stat() and open() calls close to each
other.  That doesn't mean those can't be improved by using O_NOFOLLOW
if available, but it's not high priority.

> > > People will just have to learn to not trust running standard
> > > utilities on file systems that lack reliable-enough inode numbers.
> 
> Well, for find one of the principal problems is that there's no way
> around using directory inode numbers for security checks.  On POSIX
> filesystems without O_NOFOLLOW (and perhaps some with, if the
> semantics are synthesised) there's no alternative.

Yes, for systems with O_NOFOLLOW, that is a perfect (efficient, race
free) solution.  For systems without O_NOFOLLOW, just moving the
lstat() and the open() close to each other is a reasonably good
solution, and obviously no less secure, than if the lstat() and the
open() are far apart (which is the problem with fts).

> Filesystems not having support for symbolic links don't need the
> checks.  But I can't think of a way to tell if we're looking at such a
>  filesystem.   I would expect that using readlink() won't work because
> I expect you would get EINVAL on non-supporting filesystems, just as
> you do on symlink-supporting filesystems for non-symlinks.  Creating a
> symlink to verify that you get EPERM is also something that find
> certainly shouldn't do.

I don't beleive you actually need to differentiate between different
kinds of filesystems.

Miklos