From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 Description of problem: when testing built-in test function in bash, it works unless you're root. It worked with RHL7.2. I tested only -x, and it affects behavior of autofs. My version of bash is bash-2.05a-13. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. log in as a non-root account 2. sh -c '[ -x /etc/auto.misc ]; echo $?' 3. su -c "sh -c '[ -x /etc/auto.misc ]; echo $?'" 4. su -c "sh -c '/usr/bin/test -x /etc/auto.misc; echo $?'" Actual Results: prodigy:~>>% sh -c '[ -x /etc/auto.misc ]; echo $?' 1 prodigy:~>>% sudo sh -c '[ -x /etc/auto.misc ]; echo $?' 0 prodigy:~>>% sudo sh -c '/usr/bin/test -x /etc/auto.misc; echo $?' 1 Additional info: Take a look to strace output: prodigy:~>>% strace sh -c '[ -x /etc/auto.misc ]' 2>&1 | tail -4 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 access("/etc/auto.misc", X_OK) = -1 EACCES (Permission denied) rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 _exit(1) = ? prodigy:~>>% strace /usr/bin/test -x /etc/auto.misc 2>&1 | tail -4 stat64("/etc/auto.misc", {st_mode=S_IFREG|0644, st_size=601, ...}) = 0 geteuid32() = 500 getgroups32(0x20, 0xbffff790) = 8 _exit(1) = ? As you see, bash uses access("file", X_OK), which can be true for root (man 2 access).
This is because we enabled AFS support in 7.3, and AFS doesn't support Unix file system semantics (See the code around line 100 of findcmd.c in bash). Since systems without permission support usually report all files as executable, the patch in bash 2.05b-6 should fix this while retaining AFS support.