0004682: -executable option not working

(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

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

Relationships

OpenCSW Bug Tracker