[[ -x ]] and root

[[ -x ]] and root

[Colin Holmes]

Hi,

  I am quite new to sysadm and zsh so I hope this question isn't
stupid.

  As root, I want to strip some files in a mixed bin and data
directory.  So I use "zsh# if [[ -x file ]]" to find out if the file
has --x--x--x for the current (root) process.

However, [[ -x file ]] returns true for all files when run under a root process, 
even for files --r--r--r that (correctly) fail execution for root with "permission
denied:"  

Is this a zsh "feature" or am I misunderstanding something fundamental?

Colin.

-- 

* CJ Holmes, PhD, 			
* Dept Neurology, UCLA School of Medicine, 4238 Reed Bldg, Box 951769
* 710 Westwood Plaza, Los Angeles, CA 90095-1769
* ph 310-206-2101 fx 310-206-5518 email holmes@loni.ucla.edu

Re: [[ -x ]] and root

[Zefram]

>However, [[ -x file ]] returns true for all files when run under a root process, 
>even for files --r--r--r that (correctly) fail execution for root with "permission
>denied:"  
>
>Is this a zsh "feature" or am I misunderstanding something fundamental?

It's a "feature" of most Linux kernels, that broke one of my scripts.
If you are indeed using Linux, complain to Linus -- he was sent correct
patches to fix this problem months ago, but he seems to have ignored
them.

-zefram

Re: [[ -x ]] and root

[Colin Holmes]

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:
In article <4sedhv$305q@uni.library.ucla.edu>, holmes@alzabo.loni.ucla.edu
write
s:
>  Anyone reported that the access() call in the system library
> behaves improperly with regard to root?  This has been a
> problem for me while writing root scripts under zsh.

Are you confident that zsh uses access(2) in its test -x
implementation?  That would be a mistake, I believe.

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.  As Paul says, access() has limited usefulness, and
in my experience, is often misused.
--

Dave Olson, Silicon Graphics   Guru and busybody at large


So, the folks at SGI think that the test ought to be performed
in a manner other than calling access().  I doubt they are going
to do anything to change the behaviour of access() so, if the zsh
group doesn't change the nature of the test underlying -x, I need
a workaround....  Any takers?

Colin.



-- 

* CJ Holmes, PhD, 			
* Dept Neurology, UCLA School of Medicine, 4238 Reed Bldg, Box 951769
* 710 Westwood Plaza, Los Angeles, CA 90095-1769
* ph 310-206-2101 fx 310-206-5518 email holmes@loni.ucla.edu

Re: [[ -x ]] and root

[Zefram]

>Are you confident that zsh uses access(2) in its test -x
>implementation?  That would be a mistake, I believe.

Red herring alert.

I mentioned access(2) specifically because that's the *neatest* way to
test it.  In Linux, the bug was not in access() itself, but in the
generic permission-checking code.  That code is used for access(), and
also for all the other permissions checking.  If that code is
misbehaving, access() would be one of the more directly affected
syscalls.

That said, zsh *does* in fact use access(2) for condition checking.

-zefram

Re: [[ -x ]] and root

[Bart Schaefer]

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.