[+bug-findutils since we're discussing this example in that context]
On 10/5/06, Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> 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.
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). James. _______________________________________________ Bug-findutils mailing list Bug-findutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-findutils
