> > > 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 file descriptor for each symlink > > traversed, > > But at the time we traverse the symlink, we don't know it's a symlink. > Here's the order of events: > > process 1 stats "." and remembers the resulting device and inode. > process 1 stats c. It is told that c is a directory, not a symlink. > process 1 chdirs into c. Now, CWD=/a/b/c, and that's where it thinks it is. > process 1 stats ".." and compares the device and inode with the previous > value. > - these are the same so the security check succeeds. > process 1 stats d. It is told that d is a directory, not a symlink. > process 2 renames d to d~, and creates a symlink d pointing at /g/h > process 1 chdirs into d. Now CWD=/g/h but it thinks this is /a/b/c/d > process 1 stats ".." and compares the device and inode with the previous > value. > - these are DIFFERENT so the security check FAILS. (as we would want) > > So here, We stat ".." with CWD="/g/h" to determine that it is > different to "/a/b/c". > > (this logic is taken from oldfind, I'm much less sure how fts tackels > the same situation) > > > or just ignore this problems for inode-less filesystems > > I'm very reluctant to do that. It's the rare problems that the > quality tools should worry about. Common problem the user normally > knows about and can cope with. > > > (find -L is relatively rarely used). > > It doesn't really matter that the feature is rarely used. Security > problems are bad, even if they only exist in rarely-used program > features.
The worst that can happen is that the security check makes a false alarm. That in no way makes the security weaker. > > I agree that compromises are unavoidable. > > I guess the problem doesn't arise for SMBFS, since there are no > symlinks available. Hence ofr the SMBFS case, one workaround could > be to just skip the check, but there's no easy way to tel that it is > safe to do that. > > The problem is arguably worse for SSHFS, because SFTP doesn't support > "ls -i" anyway, whereas the underlying filesystem could be susceptible > to the kinds of attacks we're talking about. > > > However the bug I originally reported was not a theoretical one, it > > was reported for a _real_ FUSE filesystem used on gentoo (which > > carries find-4.3) and very likely will be reported for > > smbfs/cifs/fat/etc sooner or later. > > Well the problem is more or less similar to the difficilties of NFSv3 > servers with NFSv2 clients, or 32-bit clients on systems where st_ino > is 64 bits (for example HPUX 11i has this property, I think). And no wonder they are similar, since in both cases the root of the problem is how to map a large ID space into a small one. Miklos _______________________________________________ Bug-findutils mailing list Bug-findutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-findutils
