[bug #27221] symlink_loop check broken by FTS_CWDFD

[Mike-742]

URL:
  <http://savannah.gnu.org/bugs/?27221>

                 Summary: symlink_loop check broken by FTS_CWDFD
                 Project: findutils
            Submitted by: gagern
            Submitted on: Mo 10 Aug 2009 18:42:37 GMT
                Category: find
                Severity: 3 - Normal
              Item Group: Wrong result
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name:
        Originator Email:
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 4.5.4
           Fixed Release: None

    _______________________________________________________

Details:

In ftsfind.c there are two calls to a function symlink_loop. Both of these
pass ent->fts_accpath as the argument, which in turn gets fed into stat resp.
lstat.

It seems that fts_accpath only contains the base name of the file, not its
full path. This behaviour is probably a consequence of the activation of the
FTS_CWDFD flag in commit 214320ca.

Either fts_path should be passed instead of fts_accpath, or fstatat would
have to be used together with fts_cwd_fd.

I saw traces of this issue in an strace output while investigating bug 27213.
So steps to reproduce this are:
$ mkdir -p foo/bar
$ chmod a-x foo
$ strace find foo
...
fstatat64(6, "bar", 0x9d72100, AT_SYMLINK_NOFOLLOW)
                        = -1 EACCES (Permission denied)
dup(6)                           = 5
fcntl64(5, F_GETFD)              = 0
fcntl64(5, F_SETFD, FD_CLOEXEC)  = 0
lstat64("bar", 0xbfb8f104)
                        = -1 ENOENT (No such file or directory)

The -L command line switch, which enables FTS_LOGICAL, will cause FTS_NOCHDIR
to be enabled, in which case fts_accpath is equal to fts_path, and things work
out fine. Therefore the example from bug #19605 can't be used to demonstrate
this issue here.

Assuming that the directory containing a node is valid, I cannot imagine a
node within where lstat could result in an ELOOP error. And invalid
directories would have to be search roots, which get a somewhat different
treatment not involving symlink_loop. In other words, I belive an unfollowed
symlink can never be a part of a symlink loop. Therefore the lstat part of
symlink_loop seems pointless.

Furthermore, I cannot imagine how a node could result in FTS_SLNONE and be
part of a loop at the same time. So the check there doesn't make sense to me.

As for the FTS_NS case: in this case I'd like to hear about loop errors, as
well as any other kind of error causing the stat information to be
unavailable. I can get the error of the stat from the fts_errno variable, so I
don't need to stat again. Doing this fixes the part of bug #27213 where I
complain about the absence of an error message for nodes in non-executable
dirs.

So I suggest:
1. Always issue an error message for NTF_NS
2. Never issue an error message for FTS_SLNONE
3. Drop the symlink_loop function, as it serves no purpose




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27221>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/