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 ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
