Anonymous | Login | 2025-01-22 17:07 UTC |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||
ID | Category | Severity | Type | Date Submitted | Last Update | ||
0000511 | [1003.1(2008)/Issue 7] System Interfaces | Objection | Omission | 2011-11-16 19:32 | 2019-06-10 08:55 | ||
Reporter | eblake | View Status | public | ||||
Assigned To | ajosey | ||||||
Priority | normal | Resolution | Accepted | ||||
Status | Closed | ||||||
Name | Eric Blake | ||||||
Organization | Red Hat | ||||||
User Reference | ebb.getuid | ||||||
Section | getuid | ||||||
Page Number | 1083 | ||||||
Line Number | 36116 | ||||||
Interp Status | --- | ||||||
Final Accepted Text | See Desired Action | ||||||
Summary | 0000511: getuid and friends should not modify errno | ||||||
Description |
The standard is clear that in a conforming environment, identification functions such as getuid() never fail. However, at least the GNU Hurd implementation has an extension where a process can exist in a non-conforming environment, and thus be outside the realms of POSIX process identifiers; on this platform, getuid() fails with a status of (uid_t)(-1) and sets errno if a program is run from a non-conforming environment. Obviously, POSIX cannot standardize this failure mode; but at the same time, POSIX should make it easier for applications written for GNU Hurd to detect this extension. Since chown() already has special handling for (uid_t)(-1), it is implicit that POSIX does not allow a valid user id matching this value; but making this limitation explicit will make it easier for implementations to use this reserved value as an indicator of the extension of getuid() failure. Additionally, POSIX states that errno is unspecified on success unless explicitly mentioned, but since all existing implementations happen to leave errno unchanged on successful getuid(), making this fact explicit means that an application on GNU Hurd can check for getuid() failure by setting errno to 0, then checking for non-zero errno after the fact (especially useful since POSIX requires that user ids are non-negative, but does not make the same requirement of uid_t; furthermore, uid_t can be narrower or wider than int, so portable checking for a result of (uid_t)(-1) is not trivial). For more details, see this thread where GNU coreutils debated about how best to let id(1) detect and gracefully fail when it is executed on GNU Hurd in an extension environment with no POSIX process identifiers: http://bugs.gnu.org/10021 [^] |
||||||
Desired Action |
At line 1855 [XBD 3.188 Group ID], add a sentence: The value (gid_t)(-1) shall not be a valid group ID, but does have a defined use in some interfaces defined in this standard. At line 2782 [XBD 3.428 User ID], add a sentence: The value (uid_t)(-1) shall not be a valid user ID, but does have a defined use in some interfaces defined in this standard. In each of the following locations, under the DESCRIPTION section, add a sentence with the appropriate function name: The FUNCTION() function shall not modify errno. 33813 getegid 33934 geteuid 33966 getgid 36116 getuid In each of the following locations, under the RATIONALE section, replace "None." with the following paragraph, with the appropriate function name and with TYPE being gid_t or uid_t as appropriate: In a conforming environment, FUNCTION() will always succeed. It is possible for implementations to provide an extension where a process in a non-conforming environment will not be associated with a user or group ID. It is recommended that such implementations return (TYPE)(-1) and set errno to indicate such an environment; doing so does not violate this standard, since such an environment is already an extension. 33824 getegid 33945 geteuid 33977 getgid 36134 getuid |
||||||
Tags | tc2-2008 | ||||||
Attached Files | |||||||
|
Relationships | ||||||
|
There are no notes attached to this issue. |
Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |