Jim,
Any news about this bug?
This problem was again reported against a recent Debian release here:
http://article.gmane.org/gmane.comp.file-systems.fuse.sshfs/1200
Thanks,
Miklos
On Wed, 16 Jun 2010, Jim Meyering wrote:
Miklos Szeredi wrote:
On Thu, 03 Jun 2010, Miklos Szeredi wrote:
Hmm, actually struct statfs on linux does have f_frsize, only the
manpage doesn't document it. So correct thing would be to use that,
no?
Here's a patch that allows df(1
On Wed, 16 Jun 2010, Jim Meyering wrote:
Miklos Szeredi wrote:
On Wed, 16 Jun 2010, Jim Meyering wrote:
Miklos Szeredi wrote:
On Thu, 03 Jun 2010, Miklos Szeredi wrote:
Hmm, actually struct statfs on linux does have f_frsize, only the
manpage doesn't document it. So correct thing
Hi,
I've tried out the CVS version of findutils+gnulib, and it does indeed
seem to fix the problem with inode-less filesystems, in addition to
using noticably less system time.
I've also found that the -xdev option of find no longer works: it
outputs just a single line for the base directory.
Separating the patch into parts wasn't really an option after all.
I've checked this in:
Looks great. Thanks.
What's the easiest way to try this out? The patch doesn't apply to
the gnulib present in findutils-4.3.1, and I have no idea how to graft
a new gnulib version into findutils.
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
That's close.
To clarify: with the current fts implementation, the interval between the
initial lstat and subsequent open of the same directory may be arbitrarily
long, but only for 2nd or subsequent command-line arguments -- which
usually translates to 2nd or subsequent members of the argv
Looking at the strace there seems to be some other room for
optimization:
open(a, O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 5
fstat64(5, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
fcntl64(5, F_SETFD, FD_CLOEXEC) = 0
Seems unnecessary, unless find was given -exec argument.
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
This one should work, since the file descriptor in the working
directory should prevent the inode from going away. Or is there
something I'm missing?
We like to have a way of searching a directory hierarchy 10 levels
deep without needing to have 10 open file descriptors.
No,
But what about symlinks?
a g
b h-a
c
f-g
The moment you traverse the f-g symlink above,
the entire tree, a/b/c/f, is no longer referenced,
so the h-a link may take you back to a new inode,
and the cycle will not be detected.
Right. So find either holds a
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
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
Shouldn't holding the current directory open prevent the ancestor from
changing inodes in this case?
No.
What's changed is the identity (dev/inode) of the parent directory,
once you try to chdir(..) up beyond the renamed directory.
I understand, that that is the case you want to
But what about symlinks?
a g
b h-a
c
f-g
The moment you traverse the f-g symlink above,
the entire tree, a/b/c/f, is no longer referenced,
so the h-a link may take you back to a new inode,
and the cycle will not be detected.
Right. So find
So I think the problem we are seeing is not for traversing up the
tree, but for traversing down it. In which case the check is not
needed (if O_NOFOLLOW is also available).
And if O_NOFOLLOW is unavailable it would still make sense to move the
stat and the open as close to each other as
But what about symlinks?
a g
b h-a
c
f-g
The moment you traverse the f-g symlink above,
the entire tree, a/b/c/f, is no longer referenced,
so the h-a link may take you back to a new inode,
and the cycle will not be detected.
Right. So
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. What I suggested is to get rid of the
check and the
Thanks for forwarding that.
I confess I hadn't looked at the original bug report.
Just did, and see that it's a different problem than I first thought.
I now see that this is about the dev/ino check when traversing up
to return to a previously visited directory.
I find it hard to believe
Look at this strace snipplet from 'find /mnt/fuse/tmp/test':
lstat64(/mnt/fuse/tmp/test, {st_dev=makedev(0, 14), st_ino=3}...) = 0
...
open (/mnt/fuse/tmp/test, O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY)
= 5
fstat64(5, {st_dev=makedev(0, 14), st_ino=5}) = 0
No file decriptor
20 matches
Mail list logo
