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

[Miklos Szeredi]

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

Thanks.

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

No I didn't edit.  You're right, that my snippet does not indicate
such a case.

However it _does_ happen for the top level directory (as you have
said) that the inital lstat may be performed much earlier, than
actually opening that directory.  That is the _real_ problem.

It's true that my test filesystem is ineffective against distingishing
between these cases.

Miklos