bug-findutils
[Top][All Lists]
Advanced

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

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


From: James Youngman
Subject: Re: [bug #17877] Invalid "No such file or directory" error on filesystem without stable inode numbers
Date: Sat, 7 Oct 2006 21:08:04 +0100

On 10/7/06, Miklos Szeredi <address@hidden> wrote:

[ JY: I assume that "> >" quotes statements by Paul Eggert, but the
attribution has been lost ]

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

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.

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.  You could perhaps use a pair of Bloom filters to
account for collisions (though this would mean that two SSHFS-using
clients might disagree about the inode number of a given file).

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

Changes within these guidelines are welcome and encouraged.   The only
patch currently attached to the bug report is one which didn't fix the
problem.


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

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.

James.




reply via email to

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