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
0000658 [1003.1(2008)/Issue 7] System Interfaces Editorial Enhancement Request 2013-02-09 02:36 2013-03-07 16:25
Reporter dalias View Status public  
Assigned To ajosey
Priority normal Resolution Open  
Status Under Review  
Name Rich Felker
Organization musl libc
User Reference
Section open
Page Number unknown
Line Number unknown
Interp Status ---
Final Accepted Text
Summary 0000658: Undefined/unspecified behavior clauses in description of open have race conditions
Description The specification for the open interface assigns undefined or unspecified behavior when certain flags are used while attempting to open certain types of files:

O_EXEC
Open for execute only (non-directory files). The result is unspecified if this flag is applied to a directory.

O_RDWR
Open for reading and writing. The result is undefined if this flag is applied to a FIFO.

O_SEARCH
Open directory for search only. The result is unspecified if this flag is applied to a non-directory file.

O_NONBLOCK
[...]
Otherwise, the behavior of O_NONBLOCK is unspecified.

Leaving such behavior unspecified or undefined contradicts the intent that open be able to avoid race conditions (the whole purpose of having the of O_EXCL flag). As-written, the standard makes it unsafe for a program to call open with any of the above flags/modes on any pathname where another user has write permission for any directory in the pathname. After an application has confirmed (via stat) that the file to be opened has the right type to avoid unspecified or undefined behavior, but before the open takes place, an attacker could replace a pathname component such that the pathname will refer to a file of an inappropriate type, causing the target process to exhibit unspecified or undefined behavior.

For O_SEARCH, it may be possible to work around this issue by also specifying O_DIRECTORY, except that the unspecified behavior seems to be invoked as soon as the function is called, not only if it succeeds in combination with the other flags provided. This would be trivial to fix.

The other cases seem somewhat harder to fix, but I think a suitable solution would be to require that the open attempts with incorrect flags either fail with an error or succeed and defer the unspecified/undefined behavior to subsequent attempts to perform an operation other than fstat on the returned file descriptor. Then, programs wishing to use these modes/flags safely could check fstat after opening the file to make sure that the file type is correct so as to ensure well-defined behavior.
Desired Action Amend the description of open to avoid file replacement race conditions that could lead to invoking unspecified or undefined behavior.
Tags No tags attached.
Attached Files

- Relationships
related to 0000141Closedajosey O_NONBLOCK flag to open 

-  Notes
(0001462)
eblake (manager)
2013-02-14 16:52

O_NONBLOCK was already fixed in 0000141; I will work on wording for the remaining three flags.
(0001482)
eblake (manager)
2013-03-07 16:25
edited on: 2013-03-07 17:29

At page 1379 line 45181 [XSH open DESCRIPTION O_EXEC], change:

The result is unspecified if this flag is applied to a directory.

to:

If path names a directory, it is unspecified whether open() fails,
or whether the directory is opened but with an unspecified access
mode.

At page 1379 line 45184 [XSH open DESCRIPTION O_RDWR], change:

The result is undefined if this flag is applied to a FIFO.

to:

If path names a FIFO, and the implementation does not support opening
a FIFO for simultaneous read and write, then open() shall fail.

At page 1379 line 45186 [XSH open DESCRIPTION O_SEARCH], change:

The result is unspecified if this flag is applied to a non-directory
file.

to:

If path names a non-directory file, it is unspecified whether open()
fails, or whether the file is opened but with an unspecified access
mode.

After page 1379 line 45188 [XSH open DESCRIPTION], add a new paragraph:

If a file is successfully opened with an unspecified access mode,
an application can use fcntl() to discover the access mode that
was selected.

At page 1382 line 45311 [XSH open ERRORS], change the following:

<SIO>[EINVAL] The implementation does not support synchronized I/O for
this file.</SIO>

to: (SIO shading applies only to the existing text, as noted):

[EINVAL] The path argument names a FIFO and O_RDWR was specified, but
the implementation considers this an error; <SIO>or synchronized I/O
flags were specified and the implementation does not support
synchronized I/O for the file.</SIO>

At page 1382 line 45314 [XSH open ERRORS EISDIR], change:

The named file is a directory and oflag includes O_WRONLY or O_RDWR.

to:

The named file is a directory and oflag includes O_WRONLY or O_RDWR,
or includes O_EXEC when O_EXEC is not the same value as O_SEARCH.

At page 1383 line 45334 [XSH open ERRORS ENOTDIR], change:

...not name a directory.

to:

...not name a directory; or the path argument names a non-directory
and O_SEARCH was specified when O_SEARCH is not the same value as
O_EXEC.

At page 1385 line 45430 [XSH open RATIONALE], change:

Since FIFOs could be implemented in other ways, and since two file
descriptors can be used to the same effect, this possibility is
left as undefined.

to:

Since FIFOs could be implemented in other ways, and since two file
descriptors can be used to the same effect, an implementation is
allowed to reject the use of O_RDWR on a FIFO.

At page 1385 line 45452 [XSH open RATIONALE], after "need not be
distinct", add a sentence:

Although the standard allows open() to fail on an attempt to use
O_EXEC on a directory, or O_SEARCH on a non-directory, this is only
possible in implementations where the two modes have distinct values.


- Issue History
Date Modified Username Field Change
2013-02-09 02:36 dalias New Issue
2013-02-09 02:36 dalias Status New => Under Review
2013-02-09 02:36 dalias Assigned To => ajosey
2013-02-09 02:36 dalias Name => Rich Felker
2013-02-09 02:36 dalias Organization => musl libc
2013-02-09 02:36 dalias Section => open
2013-02-09 02:36 dalias Page Number => unknown
2013-02-09 02:36 dalias Line Number => unknown
2013-02-14 16:46 eblake Relationship added related to 0000141
2013-02-14 16:52 eblake Note Added: 0001462
2013-03-07 16:25 eblake Note Added: 0001482
2013-03-07 17:14 eblake Note Edited: 0001482
2013-03-07 17:18 eblake Note Edited: 0001482
2013-03-07 17:25 eblake Note Edited: 0001482
2013-03-07 17:29 eblake Note Edited: 0001482


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