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

[Jim Meyering]

Miklos Szeredi <address@hidden> wrote:
>> I suspect that it is possible, and maybe even feasible, to work around
>> this violation of fundamental assumptions in some limited cases.
>> However, in general, I think it's not possible, or at least not
>> worth the effort.
>>
>> In spite of that, I have thought about changing fts to be usable even
>> in the unusual event that these inode-less file systems misbehave.
>> However, ignoring all dev/inode-based tests would raise other issues:
>>
>>   - there would be no protection against the attacks I already mentioned
>>   But a work-around is possible: rather than hard-coding the failure,
>>   provide a callback, and let the caller determine how to handle it.
>>   However, this is a lame hack: on an affected file system, there would
>>   be no way to distinguish between an attack and a directory inode number
>>   that changed due to a flushed cache.
>>   IMHO, disabling such a safety net is a very bad idea.
>
> The details of the attack are not clear to me, can you please explain?

For example, consider the classic symlink attack.
We're not supposed to follow symlinks and our system lacks support
for open's O_NOFOLLOW flag.  So we lstat the target directory,
determine that it is indeed a directory, then open it.  But between
the lstat and the open, someone moved it aside and replaced it with
a symlink to another directory.  The only way to detect that is to
compare dev/inode pairs before and after.

> Is test in fts_safe_changedir() for protecting against this?

Yes.