[[ -x file ]]

[[ -x file ]]

[Zefram]

The ChangeLog for 3.1.2-test1:
#	* Src/cond.c: [[ -x file ]] does stat for privileged users

I think this is a bad idea.  access(, X_OK) is the right way to test for
executability.  The new test gets it wrong over NFS with root squash,
and on directories with no execute bits set (which *are* executable to
the super-user).  Furthermore, with POSIX.1e capabilities, it is one
specific capability (well, two, CAP_DAC_READ_SEARCH for directories and
CAP_DAC_EXECUTE for files) that overrides normal DAC, whereas the new
code tests for *any* capability being set.

What was the reason for this change?

-zefram

Re: [[ -x file ]]

[Zoltan Hidvegi]

> The ChangeLog for 3.1.2-test1:
> #	* Src/cond.c: [[ -x file ]] does stat for privileged users
> 
> I think this is a bad idea.  access(, X_OK) is the right way to test for
> executability.  The new test gets it wrong over NFS with root squash,
> and on directories with no execute bits set (which *are* executable to
> the super-user).  Furthermore, with POSIX.1e capabilities, it is one
> specific capability (well, two, CAP_DAC_READ_SEARCH for directories and
> CAP_DAC_EXECUTE for files) that overrides normal DAC, whereas the new
> code tests for *any* capability being set.
> 
> What was the reason for this change?

access(, X_OK) simply does not work for root, it is always true, regardless
of permissions or NFS root squash.  Both ksh93 and bash does stat (ksh93
usually use access, but uses stat if it has provileges).  But you are right
that I should check if it is a directory.  I do not have POSIX.1e.  Either
send a fix using the correct POSIX.1e calls, or point me to a
documentation.  access(, X_OK) might work on an OS other than Linux, but I
seem to remember someone complaining about this using some other OS so it
seems to be a general problem.  The other problem with access is that it
uses the real instead of the effective user user/group ids.  It would be
rather complicated to fix that since this means that we need to chechk the
owner and group of the file, and compare that with the effective uid/gid
and the list of additional groups the process has )-:.

My non-current posix docs say:

    -x file      True if file exists and is executable.  True shall
                 indicate only that the execute flag is on.  If file is a
                 directory, true indicates that file can be searched.

As you can see, it does not mention real/effective ids.  Ksh93 consequently
uses the effective privileges for -x.  Bash uses stat only, and returns
false if no executable bit is set, even for root and directories.  pdksh
use access only.  This means that the three POSIX shell I have behave three
different way in this case, and ksh93 seems to be the most correct.  It
would be helpfull if someone with the latest POSIX docs can clarify this.
Note that this also affects the -r, -w, -a flags.

Zoltan