On 03/29/10 11:42, Eric Blake wrote: >>> Therefore, it is perfectly acceptable for the root user to claim that a >>> file is executable, as reported by eaccess, even if none of the file >>> permission bits grant such permission. >> >> Yes, but test should still return false if the file isn't executable by >> anybody on the system. > > If eaccess() lies and returns true even though the file is not > executable by anybody on the system (including the superuser), then that > is a bug in eaccess(), not in test(1).
The way I read the specifications, it can be OK for eaccess(2) and friends to say something's executable when it really isn't, while it's not OK for test(1) to return false positives. I still believe this is a bash bug. >> Regarding ACLs, I'm not sure they're checked on any >> other operating system either. > > YES THEY ARE. Cygwin is proof of a system that has _properly_ > implemented faccessat() in the face of ACLs. It is _entirely_ possible > for stat() to claim that a file cannot be accessed by the owner, group, > or world, but where ACLs show that the current effective id _can_ > execute it, and that is the case that faccessat is designed to detect, > which must then be fed into test -x. What I meant was that I don't think there's any consideration of ACLs in bash's built-in test. I don't seem to have any calls to faccessat() in my bash source tree. >> As far as I can see from bash's >> sh_stataccess function, "test -x" ANDs the st_mode bits with S_IXGUO. > > That's because bash's sh_stataccess is a workaround for systems that > lack POSIX 2008 compliance - no one ever claimed that the workaround is > as good as the real thing. To me it looks like whenever one does "test -x" in bash one will end up calling either eaccess(2) or stat(2). // Best wishes; Johan