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

[Jim Meyering]

Miklos Szeredi <address@hidden> wrote:
>> > In which case the check is not
>> > needed (if O_NOFOLLOW is also available).
>>
>> Unfortunately, we can't yet afford to target only systems with
>> open/O_NOFOLLOW support, and we do care about security on other systems.
>
> I think you misunderstand.

Not hardly.

> What I suggested is to get rid of the
> check and the lstat on systems which _do_ have O_NOFOLLOW.

In large part, that is already done.
However, the initial lstat of each command line argument is an
exception that is required to support the sorting of command line
arguments, possibly based on their stat data.

But none of the coreutils uses that feature of fts, so
there should be a work-around.  I'm testing a patch.
Will post it tomorrow.

> No security problem with this, is there?

You're welcome to redesign fts to avoid the current situation.

> On systems which don't have O_NOFOLLOW, move the lstat() close to (or
> even after) the open.  Again, no security issues.
>
>> The real problem is that these inode-less file systems violate
>> long-standing practice.  And *many* applications depend on being able to
>> lstat a file and (soon afterward) open the same file, and then require
>> that the before and after inodes match.
>
> With an inode-less filesystem it is very very unlikely that the inode
> number will change between an lstat and a closely following open.  As

What you're saying here is inconsistent with the strace snippet you posted
showing the offending lstat and open with almost no intervening syscalls.
Perhaps you edited it and forgot to indicate that?