zsh-workers
 help / color / mirror / code / Atom feed
From: Zoltan Hidvegi <hzoli@ny.frontiercomm.net>
To: zefram@dcs.warwick.ac.uk (Zefram)
Cc: zsh-workers@math.gatech.edu
Subject: Re: [[ -x file ]]
Date: Sun, 11 May 1997 21:04:17 -0400 (EDT)	[thread overview]
Message-ID: <199705120104.VAA03902@hzoli.home> (raw)
In-Reply-To: <16144.199705111751@stone.dcs.warwick.ac.uk> from Zefram at "May 11, 97 06:51:08 pm"

> 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


      reply	other threads:[~1997-05-12  2:15 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-05-11 17:51 Zefram
1997-05-12  1:04 ` Zoltan Hidvegi [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199705120104.VAA03902@hzoli.home \
    --to=hzoli@ny.frontiercomm.net \
    --cc=zefram@dcs.warwick.ac.uk \
    --cc=zsh-workers@math.gatech.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).