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