bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Built-in "test -x" fails for root on FreeBSD


From: Johan Hattne
Subject: Re: Built-in "test -x" fails for root on FreeBSD
Date: Mon, 29 Mar 2010 11:36:28 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100325 Thunderbird/3.0.3

On 03/29/10 09:01, Eric Blake wrote:
> On 03/26/2010 11:47 PM, Johan Hattne wrote:
>> Description:
>>   The bash built-in test command fails to correctly report executable
>>   status for non-executable files when run by root on FreeBSD.
> 
> Not a bug.  POSIX states for test -x:
> 
> True if pathname resolves to an existing directory entry for a file for
> which permission to execute the file (or search it, if it is a
> directory) will be granted, as defined in File Read, Write, and Creation.
> http://www.opengroup.org/onlinepubs/9699919799/utilities/test.html

But the last sentence in the paragraph quoted states "False if pathname
cannot be resolved, or if pathname resolves to an existing directory
entry for a file for which permission to execute (or search) the file
will not be granted".

>If a process has appropriate privileges:
...
>     * If execute permission is requested, access shall be granted if
> execute permission is granted to at least one user by the file
> permission bits or by an alternate access control mechanism; otherwise,
> access shall be denied.
> 
> http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_04

I'm OK with that--for root, "test -x" should return true as long as
there exists at least one user who has execute permission.

> It also states for faccessat (eaccess is a non-portable interface
> comparable to the standardized faccessat):

But faccessat() does not really have anything to do with test?

> If any access permissions are checked, each shall be checked
> individually, as described in XBD File Access Permissions , except that
> where that description refers to execute permission for a process with
> appropriate privileges, an implementation may indicate success for X_OK
> even if execute permission is not granted to any user.
> http://www.opengroup.org/onlinepubs/9699919799/functions/access.html

Yes, so the FreeBSD access functions don't break the Open Goup
specification.

> Therefore, it is perfectly acceptable for the root user to claim that a
> file is executable, as reported by eaccess, even if none of the file
> permission bits grant such permission.

Yes, but test should still return false if the file isn't executable by
anybody on the system.

>>  #if defined (HAVE_EACCESS)        /* FreeBSD */
>> -  return (eaccess (path, mode));
>> +  if (stat (path, &s) != 0)
>> +    return (-1);
>> +  ret = eaccess (path, mode);
>> +  if (mode == X_OK && ret == 0 && !S_ISDIR(s.st_mode) && geteuid() == 0)
>> +    return ((s.st_mode & (S_IXUSR | S_IXGRP | S_IXOTH)) == 0 ? -1 : 0);
>> +  return (ret);
> 
> This patch fails to take into account ACLs, which is one of the reasons
> that faccessat was standardized.

But faccessat() is equivalent to access() except in the case where the
path is relative?  Regarding ACLs, I'm not sure they're checked on any
other operating system either.  As far as I can see from bash's
sh_stataccess function, "test -x" ANDs the st_mode bits with S_IXGUO.

// Best wishes; Johan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]