[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #27221] symlink_loop check broken by FTS_CWDFD
From: |
Martin von Gagern |
Subject: |
[bug #27221] symlink_loop check broken by FTS_CWDFD |
Date: |
Mon, 10 Aug 2009 18:42:38 +0000 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.2) Gecko/20090806 Gentoo Firefox/3.5.2 |
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/
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [bug #27221] symlink_loop check broken by FTS_CWDFD,
Martin von Gagern <=