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
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
related to 0000555Closedajosey the incestuous relationship of fclose(stderr) and STDERR_FILENO 

-  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
Powered by Mantis Bugtracker