Anonymous | Login | 2024-03-29 13:42 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 | ||
0000173 | [1003.1(2008)/Issue 7] System Interfaces | Objection | Clarification Requested | 2009-10-29 10:32 | 2013-04-16 13:06 | ||
Reporter | geoffclare | View Status | public | ||||
Assigned To | ajosey | ||||||
Priority | normal | Resolution | Accepted | ||||
Status | Closed | ||||||
Name | Geoff Clare | ||||||
Organization | The Open Group | ||||||
User Reference | |||||||
Section | exec | ||||||
Page Number | 773 | ||||||
Line Number | 25757 | ||||||
Interp Status | Approved | ||||||
Final Accepted Text | Note: 0000297 | ||||||
Summary | 0000173: Executing programs with "bad" file descriptors 0, 1 or 2 | ||||||
Description |
XSH7 section 2.5 states: "At program start-up, three streams are predefined and need not be opened explicitly: standard input (for reading conventional input), standard output (for writing conventional output), and standard error (for writing diagnostic output)." The standard also provides the means to execute programs with fd 0 not open for reading, or fd 1 or 2 not open for writing. However, it does not fully address the issue of what happens to stdin, stdout and stderr when a conforming application is executed in such a way. The security aspects of the issue were addressed in SUSv3 TC1, which resulted in implementations being allowed to automatically open these fds when executing set-user-ID or set-group-ID programs (although it only says this for exec, not for posix_spawn or the shell). At the same time a note was added to exec() application usage saying: "Applications should not depend on file descriptors 0, 1, and 2 being closed after an exec. A future version may allow these file descriptors to be automatically opened for any process." I think we should make this change to allow implementations to do the automatic open for any process. However, the issue would still remain of what happens on implementations which do not open them, and what happens if they are open but not readable (fd 0) or not writable (fd 1 or 2). In practice, I believe what happens is that the stdin, stdout and stderr streams are created and their underlying file descriptors are set to 0, 1 and 2 respectively, regardless of whether they are open or closed, and regardless of whether fd 0 is readable or fd 1 or 2 is writable. At first sight, it would seem that a simple solution is just to modify section 2.5 to describe this existing practice. The problem with this solution is that the guarantee in section 2.5 about stdin, stdout and stderr being open (and readable/writable) at program startup comes from the C Standard. I don't believe a modification of this nature would be a valid extension to the C Standard - it would create a conflict. I believe an appropriate solution would be to state that if a program is executed with fd 0 not open for reading or with fd 1 or 2 not open for writing then this means the program is not executed in a conforming environment. Thus the program is not required to behave as described in the standards (C and POSIX). There is also a similar issue for the standard utilities, in that they may misbehave in odd ways if executed with fd 0 not open for reading or with fd 1 or 2 not open for writing. The solution for applications could be used to solve this issue as well. |
||||||
Desired Action |
At page 773 line 25757 section exec, change: If file descriptors 0, 1, and 2 would otherwise be closed after a successful call to one of the exec family of functions, and the new process image file has the set-user-ID or set-group-ID file mode bits set, and the ST_NOSUID bit is not set for the file system containing the new process image file, implementations may open an unspecified file for each of these file descriptors in the new process image. to: If file descriptor 0, 1, or 2 would otherwise be closed after a successful call to one of the exec family of functions, implementations may open an unspecified file for the file descriptor in the new process image. If a standard utility or a conforming application is executed with file descriptor 0 not open for reading or with file descriptor 1 or 2 not open for writing, the environment in which the utility or application is executed shall be deemed non-conforming, and consequently the utility or application might not behave as described in this standard. At page 779 line 25993 section exec, change: Applications should not depend on file descriptors 0, 1, and 2 being closed after an exec. A future version may allow these file descriptors to be automatically opened for any process. to: Applications should not execute programs with file descriptor 0 not open for reading or with file descriptor 1 or 2 not open for writing, as this might cause the executed program to misbehave. In order not to pass on these file descriptors to an executed program, applications should not just close them but should reopen them on, for example, /dev/null. Some implementations may reopen them automatically, but applications should not rely on this being done. After page 1423 line 46584 section posix_spawn, add a new paragraph: If file descriptor 0, 1, or 2 would otherwise be closed in the new process image created by posix_spawn() or posix_spawnp(), implementations may open an unspecified file for the file descriptor in the new process image. If a standard utility or a conforming application is executed with file descriptor 0 not open for reading or with file descriptor 1 or 2 not open for writing, the environment in which the utility or application is executed shall be deemed non-conforming, and consequently the utility or application might not behave as described in this standard. After page 1425 line 46681 section posix_spawn, add: See also the APPLICATION USAGE section for [xref to exec()]. Cross-volume change to XCU ... At page 2318 line 73173 section 2.9.1.1, add a new paragraph after the numbered list (indented the same as line 73119): If the utility would be executed with file descriptor 0, 1, or 2 closed, implementations may execute the utility with the file descriptor open to an unspecified file. If a standard utility or a conforming application is executed with file descriptor 0 not open for reading or with file descriptor 1 or 2 not open for writing, the environment in which the utility or application is executed shall be deemed non-conforming, and consequently the utility or application might not behave as described in this standard. Cross-volume changes to XRAT ... After page 3660 line 124527 section C.2.7, add a new paragraph: Applications should not use the [n]<&- or [n]>&- operators to execute a utility or application with file descriptor 0 not open for reading or with file descriptor 1 or 2 not open for writing, as this might cause the executed program (or shell builtin) to misbehave. In order not to pass on these file descriptors to an executed utility or application, applications should not just close them but should reopen them on, for example, /dev/null. Some implementations may reopen them automatically, but applications should not rely on this being done. After page 3517 line 118482 section B.2.5, add: Although the C Standard guarantees that, at program start-up, stdin is open for reading and stdout and stderr are open for writing, this guarantee is contingent (as are all guarantees made by the C and POSIX standards) on the program being executed in a conforming environment. Programs executed with file descriptor 0 not open for reading or with file descriptor 1 or 2 not open for writing are executed in a non-conforming environment. Application writers are warned (in [xref to exec()], [xref to posix_spawn()], and [xref to C.2.7]) not to execute a standard utility or a conforming application with file descriptor 0 not open for reading or with file descriptor 1 or 2 not open for writing. |
||||||
Tags | c99, tc1-2008 | ||||||
Attached Files | |||||||
|
Relationships | ||||||
|
Notes | |
(0000268) eblake (manager) 2009-10-29 14:26 |
The standard also states, with CX shading, that stderr is open for both reading and writing (line 62762), although few applications ever use functions like fread on stderr. The proposed wording needs to be tweaked to cover stderr behavior when fd 2 is write-only, or we need to relax the requirement and allow stderr to be write-only if fd 2 was inherited with O_WRONLY rather than O_RDWR. |
(0000269) eblake (manager) 2009-10-29 14:33 |
This proposal also needs to consider effects on other parts of the standard that mandate what happens when one of the standard descriptors is closed. For example, nohup (line 98099) currently requires a particular behavior if "standard output either is a terminal or is closed". Does that requirement still make sense if starting nohup with stdout closed is non-compliant to begin with? |
(0000270) geoffclare (manager) 2009-10-29 16:26 |
Re: Note: 0000268 The actual statement on line 62762 (on the stdin page) is: "The stderr stream is expected to be open for reading and writing." It's not clear what is doing the expecting. It certainly can't be applications that expect it, as it is quite normal for an application to be executed from the shell using "2>..." redirection. I suspect the statement is something to do with the more utility reading from fd 2, but in that case the statement is quite wrong. It should be about fd 2 not about the stderr stream. Re: Note: 0000269 I think these need to be handled on a case by case basis. In the case of nohup, the requirement on nohup should probably be kept and an exception stated in the new additions about non-conforming environments. |
(0000297) msbrown (manager) 2009-11-12 16:30 edited on: 2009-12-03 16:13 |
Interpretation response ------------------------ The standard does not speak to this issue, and as such no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Applications should not execute programs with file descriptor 0 not open for reading or with file descriptor 1 or 2 not open for writing, as this might cause the executed program to misbehave. Rationale: ------------- None. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- Make the change suggested by the submitter. |
(0000400) nick (manager) 2010-03-25 15:10 |
On Fri, 2010-02-12 at 08:53 -0500, Glen Seeds wrote: Sorry to be so late on this. The new proposed text says: If file descriptor 0, 1, or 2 would otherwise be closed after a successful call to one of the exec family of functions, implementations may open an unspecified file for the file descriptor in the new process image. "Unspecified" usually is intended to warn application writers away from something altogether. Historically, we have tried to accommodate useful non-standard behaviour by declaring it "implementation defined". Would that not be desirable here? /glen |
(0000401) nick (manager) 2010-03-25 15:11 |
We intended "unspecified". Implementation defined also carries documentation requirements. |
Issue History | |||
Date Modified | Username | Field | Change |
2009-10-29 10:32 | geoffclare | New Issue | |
2009-10-29 10:32 | geoffclare | Status | New => Under Review |
2009-10-29 10:32 | geoffclare | Assigned To | => ajosey |
2009-10-29 10:32 | geoffclare | Name | => Geoff Clare |
2009-10-29 10:32 | geoffclare | Organization | => The Open Group |
2009-10-29 10:32 | geoffclare | Section | => exec |
2009-10-29 10:32 | geoffclare | Page Number | => 773 |
2009-10-29 10:32 | geoffclare | Line Number | => 25757 |
2009-10-29 10:32 | geoffclare | Interp Status | => --- |
2009-10-29 14:26 | eblake | Note Added: 0000268 | |
2009-10-29 14:33 | eblake | Note Added: 0000269 | |
2009-10-29 16:26 | geoffclare | Note Added: 0000270 | |
2009-11-12 16:20 | nick | Tag Attached: c99 | |
2009-11-12 16:30 | msbrown | Interp Status | --- => Pending |
2009-11-12 16:30 | msbrown | Note Added: 0000297 | |
2009-11-12 16:30 | msbrown | Status | Under Review => Interpretation Required |
2009-11-12 16:30 | msbrown | Resolution | Open => Accepted |
2009-11-12 16:31 | msbrown | Final Accepted Text | => Note: 0000297 |
2009-11-12 16:31 | msbrown | Resolution | Accepted => Accepted As Marked |
2009-12-03 16:10 | geoffclare | Resolution | Accepted As Marked => Accepted |
2009-12-03 16:13 | geoffclare | Note Edited: 0000297 | |
2010-02-12 06:37 | ajosey | Interp Status | Pending => Proposed |
2010-03-25 15:10 | nick | Note Added: 0000400 | |
2010-03-25 15:11 | nick | Note Added: 0000401 | |
2010-03-25 15:11 | msbrown | Interp Status | Proposed => Approved |
2010-09-24 14:16 | Don Cragun | Tag Attached: tc1-2008 | |
2012-05-10 15:41 | eblake | Relationship added | related to 0000555 |
2013-04-16 13:06 | ajosey | Status | Interpretation Required => Closed |
Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |