Notes |
(0009045)
jay (reporter)
2011-05-14 14:55
|
The -executable test uses faccessat(2). A system call trace (run on the smallest tree on which the problem can be reproduced) would help. |
|
(0009080)
flod (reporter)
2011-05-26 01:15
|
setup:
CSWfindutils 4.4.2,REV=2011.04.04
SunOS sun 5.10 Generic_144489-14 i86pc i386 i86pc
/tmp/test> la
insgesamt 8
drwxr-x--- 2 root root 178 26. Mai 01:07 .
drwxrwxrwt 3 root sys 308 26. Mai 01:07 ..
---------- 1 root root 0 26. Mai 01:07 file
--
relevant output of truss gfind . -executable :
[...]
open64(".", O_RDONLY|O_LARGEFILE) = 3
fchdir(3) = 0
fstatat64(-3041965, ".", 0x080A8764, 0x00001000) = 0
open64(".", O_RDONLY|O_NONBLOCK|O_NOCTTY) = 4
fchdir(4) = 0
access(".", X_OK) = 0
ioctl(1, TCGETA, 0x08046654) = 0
fstat64(1, 0x080465C0) = 0
.
write(1, " .\n", 2) = 2
openat(-3041965, ".", O_RDONLY|O_NDELAY|O_LARGEFILE) = 5
fcntl(5, F_SETFD, 0x00000001) = 0
fstat64(5, 0x08047850) = 0
fstat64(5, 0x08047860) = 0
fchdir(5) = 0
getdents64(5, 0xFEF34000, 8192) = 72
getdents64(5, 0xFEF34000, 8192) = 0
close(5) = 0
fstatat64(-3041965, "file", 0x080A8A9C, 0x00001000) = 0
access("file", X_OK) = 0
./file
write(1, " . / f i l e\n", 7) = 7
[...]
--
output:
.
./file
expected output:
.
Does that help? |
|
(0009081)
jay (reporter)
2011-05-26 01:38
|
Yes. If access(2) says the file is executable, then the -executable test correctly returns true. From the find documentation:
-executable
Matches files which are executable and directories which are
searchable (in a file name resolution sense). This takes into
account access control lists and other permissions artefacts
which the -perm test ignores. This test makes use of the
access(2) system call, and so can be fooled by NFS servers which
do UID mapping (or root-squashing), since many systems implement
access(2) in the client's kernel and so cannot make use of the
UID mapping information held on the server. Because this test
is based only on the result of the access(2) system call, there
is no guarantee that a file for which this test succeeds can
actually be executed. |
|
(0009082)
jay (reporter)
2011-05-26 01:42
|
So, find is behaving correctly and as documented. This is not a findutils bug.
You might want to find out why access(2) indicates that a file is executable when an actual attempt to execute it will fail. |
|
(0009083)
flod (reporter)
2011-05-26 14:01
|
Okay, thank you for explaining that issue. I read the man page in the first place but never expected that the syscall could be the source.
From access(2):
If any access permissions are to be checked, each will be
checked individually, as described in intro(2). If the pro-
cess has appropriate privileges, an implementation may indi-
cate success for X_OK even if none of the execute file per-
mission bits are set.
I am not sure what appropriate privileges here mean (file_dac_execute?).
I observed the strang behaviour only as root user, maybe root has some privileges (all) in the context of access().
Please close. |
|
(0009084)
bwalton (administrator)
2011-05-26 16:10
|
+tag:notabug
-Ben |
|