zsh-users
 help / color / mirror / code / Atom feed
From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: "Colin Holmes" <colin@fuligin.loni.ucla.edu>, zsh-users@math.gatech.edu
Subject: Re: [[ -x ]] and root
Date: Tue, 16 Jul 1996 14:05:18 -0700	[thread overview]
Message-ID: <9607161405.ZM1099@candle.brasslantern.com> (raw)
In-Reply-To: "Colin Holmes" <colin@fuligin.loni.ucla.edu> "Re: [[ -x ]] and root" (Jul 16, 10:57am)

On Jul 16, 10:57am, Colin Holmes wrote:
> Subject: Re: [[ -x ]] and root
> Hi again,
> 
>  I started this thread looking for a way to do a [[ -x file]] while
> running as root.  I got responses from this list (Zefram, mostly) to
> the effect that access() was improperly functioning under Irix 5.3, as
> it was under Linux.  I posted to comp.sys.sgi.bug to find out what they
> thought and here are the more useful results....
> 
> Response 1:
> The access(2) system call is intended for use by setuid
> executables, trying to determine if the real id of the process,
> as opposed to the effective, could access a particular file.
> 
> Implementations of test -x should stat and look at mode bits.
> 
> Response 2:
> It's not a problem, it's the way it's designed and supposed
> to work.

Response 1 is correct as far as it goes, but if response 2 is claiming
that access(X_OK) is ever intended to return 0 for a file that has NONE
of the execute bits set, then I'd like to see more of his explanation.
It almost sounds like they didn't understand the question.

It is definitely the case that access() can return misleading results
if geteuid() != getuid() or (on some systems, including IRIX) if
getegid() != getgid().  However, the results ought to be correct for
at least one of the IDs.

Using stat() and examining mode bits is possible, but on systems that
support supplementary groups you have to get the group ID of the file
and the list of supplemental groups of the process, and then walk the
list to see if the file's group is present.  It's messy to #ifdef for
complete portability, too.

As a workaround in your zsh scripts, glob qualifiers [which do use
stat()] can eliminate files that do not have an execute bit set.

	executable() {
	    setopt localoptions nullglob
	    local x ret=1 files=(${^*}(xEX))
	    for x in $files
	    do [[ -x $x ]] && echo $x && ret=0
	    done
	    return $ret
	}

As a quick hack, you can probably replace [[ -x foo ]] in your scripts
with [[ -x $(setopt nobadpattern; echo foo(xEX)) ]].  It's unlikely
that a file with "(xEX)" in its name is going to be encountered.



  parent reply	other threads:[~1996-07-16 21:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1996-07-16 17:57 Colin Holmes
1996-07-16 19:41 ` Zefram
1996-07-16 21:05 ` Bart Schaefer [this message]
  -- strict thread matches above, loose matches on Subject: below --
1996-07-15 17:26 Colin Holmes
1996-07-15 17:53 ` Zefram

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=9607161405.ZM1099@candle.brasslantern.com \
    --to=schaefer@candle.brasslantern.com \
    --cc=colin@fuligin.loni.ucla.edu \
    --cc=schaefer@nbn.com \
    --cc=zsh-users@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).