bug-bash
[Top][All Lists]
Advanced

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

Re: access(2) shouldn't be used with test(1)


From: Eric Blake
Subject: Re: access(2) shouldn't be used with test(1)
Date: Tue, 20 Jul 2010 15:29:31 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100621 Fedora/3.0.5-1.fc13 Lightning/1.0b2pre Mnenhy/0.8.3 Thunderbird/3.0.5

On 07/20/2010 03:22 PM, Garrett Cooper wrote:
> Correct.
> 
>> Sounds like a bug to me....   if a file isn't executable, I don't care
>> how "super" you are -- permission won't make a text file executable!
>> ;-)
> 
> Yes, but POSIX says that it's allowed to be broken based on past
> behavior, and FreeBSD just says "don't use access, act on the file",
> which means that access on FreeBSD is only really useful for F_OK, but
> I can get that from open/fstat/whatever.

POSIX says:
http://www.opengroup.org/onlinepubs/9699919799/functions/access.html

Normative:
"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."

Descriptive:
"In early proposals, some inadequacies in the access() function led to
the creation of an eaccess() function because:

   1.

      Historical implementations of access() do not test file access
correctly when the process' real user ID is superuser. In particular,
they always return zero when testing execute permissions without regard
to whether the file is executable.
   2.

      The superuser has complete access to all files on a system. As a
consequence, programs started by the superuser and switched to the
effective user ID with lesser privileges cannot use access() to test
their file access permissions.

However, the historical model of eaccess() does not resolve problem (1),
so this volume of POSIX.1-2008 now allows access() to behave in the
desired way because several implementations have corrected the problem.
It was also argued that problem (2) is more easily solved by using
open(), chdir(), or one of the exec functions as appropriate and
responding to the error, rather than creating a new function that would
not be as reliable. Therefore, eaccess() is not included in this volume
of POSIX.1-2008.

The sentence concerning appropriate privileges and execute permission
bits reflects the two possibilities implemented by historical
implementations when checking superuser access for X_OK.

New implementations are discouraged from returning X_OK unless at least
one execution permission bit is set."


Thus, access(2) _may_ say X_OK for the superuser, regardless of whether
stat()/ACL say anyone can execute, based on historical behavior,
although this historical behavior is frowned upon.  However, nowhere
does POSIX allow R_OK or W_OK to return true if stat()/ACL don't grant
read/write privileges to someone, and as long as access() is doing the
permission check for rw, it shouldn't be too hard to patch it to also do
the permission check for x.

So, if FreeBSD is poor QoI because of POSIX, it had better only be for
'test -x' and not for 'test -r' or 'test -w'.

Meanwhile, POSIX says that access(a,b) and faccessat(AT_FDCWD,a,b,0)
must be identical in behavior.

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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