Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0000838 [1003.1(2013)/Issue7+TC1] System Interfaces Editorial Clarification Requested 2014-04-28 01:04 2019-06-10 08:54
Reporter mdempsky View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Matthew Dempsky
Organization OpenBSD
User Reference
Section access
Page Number http://pubs.opengroup.org/onlinepubs/9699919799/functions/access.html [^]
Line Number
Interp Status Approved
Final Accepted Text Note: 0002247
Summary 0000838: Unclear wording about how real IDs are used
Description POSIX says "The access() function shall check the file named by the pathname pointed to by the path argument for accessibility according to the bit pattern contained in amode, using the real user ID in place of the effective user ID and the real group ID in place of the effective group ID."

This wording seems somewhat ambiguous to me whether the real user/group IDs are also used to resolve the pathname (i.e., check directory search permissions), or only to access check the file it names. E.g., arguably the spec is saying to access check the **file** according to amode and the real IDs, and the prepositional phrase "named by the pathname pointed to by the path argument" is just specifying which file is checked this way.

Linux, FreeBSD, and NetBSD use the real IDs for both resolving the path and access checking the file mode. OpenBSD currently uses the effective IDs for resolving the path and then the real IDs only for access checking the file mode, but this will likely change in the next release.
Desired Action Change

    , using the real user ID in place of the effective user ID and the real group ID in place of the effective group ID.

to

    . The checks for accessibility (including path resolution) are performed using the real user ID in place of the effective user ID and the real group ID in place of the effective group ID.

Also, perhaps add the same parenthetical remark to the text describing AT_EACCESS later in the same section.
Tags tc2-2008
Attached Files

- Relationships

-  Notes
(0002236)
geoffclare (manager)
2014-04-28 10:02

We need to find out what AIX, HP-UX, OS X, and Solaris do here. If
any of them use the effective IDs for pathname resolution, the
standard should say that it is unspecified which is used, rather than
requiring use of the real IDs.

Since this issue has been raised, perhaps we should take this
opportunity to consider what to do about access(), given its many
problems:

* It is broken by design, in that its use automatically leads to
a TOCTTOU race condition (and therefore it is only safe to use if
the file being tested is in a secure directory).

* On systems where "appropriate privileges" are granted based on
user ID, it is not clear whether access() should use the privileges
associated with the real user ID when testing permissions, although
this seems to be the intention.

* On systems where "appropriate privileges" are not granted based on
user ID, it is not clear whether access() should still use the
privileges associated with the calling process when testing
permissions. (Presumably this is not the intention.)

* It is not clear how access() interacts with additional or alternate
file access control mechanisms.

* The description of access() refers explicitly to XBD 4.4 when
specifying how the permissions are checked, but there is no mention
of XBD 4.2 and thus it is not clear what effect S_ISVTX has when
testing a directory for write permission.

So as well as addressing the issue raised in this bug, I propose
that we also do the following:

Add an LY margin code meaning "Legacy". The description of the code
should say that interfaces marked LY are retained for backwards
compatibility only and should not be used in new applications.

Add LY shading to the access() function, and alter the description
of faccessat() so that it says the flag argument can be either 0 or
AT_EACCES, with the 0 value shaded LY.

Update the description to deal with the bullet points above.

Add application usage explaining the problems with access() and
warning application writers not to use it.
(0002247)
geoffclare (manager)
2014-05-09 14:54
edited on: 2014-05-22 15:07

Interpretation response
------------------------
The standard clearly states that access() checks file accessibility
using the real user ID and real group ID in place of the effective
IDs, and conforming implementations must conform to this.

Rationale:
-------------
The standard requires that access() uses the real user ID and group ID
instead of the effective IDs when checking file accessibility, and this
applies to all aspects of accessibility that would normally be based
on the effective IDs, including directory permission checks during
pathname resolution. It also affects any appropriate privileges that
are granted based on user or group ID and any alternate or additional
file access control mechanisms that are based on user or group IDs.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------

At page 565 line 9576 section access() change:
... for accessibility according to the bit pattern contained in amode, using the real user ID in place of the effective user ID and the real group ID in place of the effective group ID.

to:
... for accessibility according to the bit pattern contained in amode. The checks for accessibility (including directory permissions checked during pathname resolution) shall be performed using the real user ID in place of the effective user ID and the real group ID in place of the effective group ID.


At page 565 line 19584 section access() change:
The faccessat() function shall be equivalent to the access() function, except ...

to:
The faccessat() function when called with a flag value of zero shall be equivalent to the access() function, except ...


At page 565 line 19595 section access() change:
The checks for accessibility are performed using the effective user and group IDs instead of the real user and group ID

to:
The checks for accessibility (including directory permissions checked during pathname resolution) shall be performed using the effective user ID and group ID instead of the real user ID and group ID


At page 566 line 19643 section access() add the following paragraphs to the beginning of the APPLICATION USAGE section:
Use of these functions is discouraged since by the time the returned information is acted upon, it is out of date. (That is, acting upon the information always leads to a time-of-check-to-time-of-use race condition.) An application should instead attempt the action itself and handle the EACCES error that occurs if the file is not accessible (with a change of effective user and group IDs beforehand, and perhaps a change back afterwards, in the case where access() or faccessat() without AT_EACCES would have been used.)

Historically, one of the uses of access() was in set-user-ID root programs to check whether the user running the program had access to a file. This relied on "super-user" privileges which were granted based on the effective user ID being zero, so that when access() used the real user ID to check accessibility those privileges were not taken into account. On newer systems where privileges can be assigned which have no association with user or group IDs, if a program with such privileges calls access(), the change of IDs has no effect on the privileges and therefore they are taken into account in the accessibility checks. Thus access() (and faccessat() with flag zero) cannot be used for this historical purpose in such programs. Likewise, if a system provides any additional or alternate file access control mechanisms that are not user ID based, they will still be taken into account.

If a relative pathname is used, no account is taken of whether the current directory (or the directory associated with the file descriptor fd) is accessible via any absolute pathname. Applications using access(), or faccessat() without AT_EACCES, may consequently act as if the file would be accessible to a user with the real user ID and group ID of the process when such a user would not in practice be able to access the file because access would be denied at some point above the current directory (or the directory associated with the file descriptor fd) in the file hierarchy.

If access() or faccessat() is used with W_OK to check for write access to a directory which has the S_ISVTX bit set, a return value indicating the directory is writable can be misleading since some operations on files in the directory would not be permitted based on the ownership of those files (see [xref to XBD 4.2]).


At page 567 line 19672 section access() change FUTURE DIRECTIONS from:
None.

to:
These functions may be formally deprecated (for example by shading them OB) in a future revision of this standard.


(0002252)
ajosey (manager)
2014-05-23 13:19

Interpretation Proposed 23 May 2014
(0002277)
ajosey (manager)
2014-06-25 10:13

Interpretation approved 25 June 2014

- Issue History
Date Modified Username Field Change
2014-04-28 01:04 mdempsky New Issue
2014-04-28 01:04 mdempsky Name => Matthew Dempsky
2014-04-28 01:04 mdempsky Organization => OpenBSD
2014-04-28 01:04 mdempsky Section => access
2014-04-28 01:04 mdempsky Page Number => http://pubs.opengroup.org/onlinepubs/9699919799/functions/access.html [^]
2014-04-28 10:02 geoffclare Note Added: 0002236
2014-05-09 14:54 geoffclare Note Added: 0002247
2014-05-09 14:58 geoffclare Note Edited: 0002247
2014-05-09 15:01 geoffclare Note View State: public: 2247
2014-05-22 15:07 geoffclare Note Edited: 0002247
2014-05-22 15:09 geoffclare Interp Status => Pending
2014-05-22 15:09 geoffclare Final Accepted Text => Note: 0002247
2014-05-22 15:09 geoffclare Status New => Interpretation Required
2014-05-22 15:09 geoffclare Resolution Open => Accepted As Marked
2014-05-22 15:09 geoffclare Tag Attached: tc2-2008
2014-05-23 13:19 ajosey Interp Status Pending => Proposed
2014-05-23 13:19 ajosey Note Added: 0002252
2014-06-25 10:13 ajosey Interp Status Proposed => Approved
2014-06-25 10:13 ajosey Note Added: 0002277
2019-06-10 08:54 agadmin Status Interpretation Required => Closed


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker