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
0001364 [Issue 8 drafts] Shell and Utilities Comment Clarification Requested 2020-07-06 10:45 2024-06-11 09:12
Reporter geoffclare View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Closed   Product Version Draft 1
Name Geoff Clare
Organization The Open Group
User Reference
Section 2.7.2 Redirecting Output
Page Number 2287
Line Number 73909
Final Accepted Text Note: 0004991
Summary 0001364: use of noclobber with files in /tmp
Description Some time after bug 0001016 was approved as an interpretation, Note: 0003655 was added in which McDutchie observed that the statement "Performing these operations atomically ensures that the creation of lock files and unique (often temporary) files is reliable" is not true if the file is in a public directory such as /tmp, since another user could create a FIFO or device file with the same name.
Desired Action On page 2287 line 73900 section 2.7.2, and
page 3587 line 124071 section C.2.7.2, add to the "Notes to Reviewers":
If option 2 is adopted in a future draft, note that the change from <URL> will need to be reapplied to the option 2 text.

where <URL> is the URL for this bug.

On page 2287 line 73909 section 2.7.2, change:
Performing these operations atomically ensures that the creation of lock files and unique (often temporary) files is reliable.
to:
Performing these operations atomically ensures that the creation of lock files and unique (often temporary) files is reliable, provided the files are created in a private directory (i.e. not in /tmp or similar).

On page 3588 line 124127 section C.2.7.2, change:
The standard developers consider this to be of less importance than ensuring that the creation of lock files is reliable.
to:
The standard developers consider this to be of less importance than ensuring that the creation of lock files is reliable (in a private directory).

Creation of lock files and unique (often temporary) files with noclobber set is only reliable provided the files are created in a private directory. If a directory such as /tmp is used where other users can create files, then another user could create a FIFO (or a device file, given sufficient privilege) with the same name, causing multiple redirections with noclobber set to open the existing non-regular file instead of one succeeding and the others failing.

Tags issue8
Attached Files

- Relationships
related to 0001016Closed 1003.1(2013)/Issue7+TC1 race condition with set -C 

-  Notes
(0004991)
rhansen (manager)
2020-09-14 15:35
edited on: 2020-09-14 15:36

On page 2287 line 73900 section 2.7.2, and
page 3587 line 124071 section C.2.7.2, add to the "Notes to Reviewers":
If option 2 is adopted in a future draft, note that the change from https://www.austingroupbugs.net/view.php?id=1364 [^] will need to be reapplied to the option 2 text.

On page 2287 line 73909 section 2.7.2, change:
Performing these operations atomically ensures that the creation of lock files and unique (often temporary) files is reliable.
to:
Performing these operations atomically ensures that the creation of lock files and unique (often temporary) files is reliable, with important caveats detailed in [xref to XRAT C.2.7.2].

On page 3588 line 124127 section C.2.7.2, change:
The standard developers consider this to be of less importance than ensuring that the creation of lock files is reliable.
to:
The standard developers consider reliable lock creation to be more important than the creation of symbolic link targets.

Creation of lock files and unique (often temporary) files with noclobber set is only reliable provided neither non-regular files nor symbolic links to non-regular files exist or are created in the same directory with the same names, and no other processes delete the files while still in use. If a directory such as /tmp is used for lock files, then another process could accidentally or maliciously create a FIFO (or a special file, given sufficient privilege) with the same name, causing multiple processes to simultaneously open the same lock file instead of one succeeding and the others failing.



- Issue History
Date Modified Username Field Change
2020-07-06 10:45 geoffclare New Issue
2020-07-06 10:45 geoffclare Name => Geoff Clare
2020-07-06 10:45 geoffclare Organization => The Open Group
2020-07-06 10:45 geoffclare Section => 2.7.2 Redirecting Output
2020-07-06 10:45 geoffclare Page Number => 2287
2020-07-06 10:45 geoffclare Line Number => 73909
2020-07-06 10:46 geoffclare Relationship added related to 0001016
2020-09-14 15:35 rhansen Note Added: 0004991
2020-09-14 15:35 rhansen Note Edited: 0004991
2020-09-14 15:36 rhansen Note Edited: 0004991
2020-09-14 15:36 rhansen Note Edited: 0004991
2020-09-14 15:36 rhansen Note Edited: 0004991
2020-09-14 15:37 rhansen Tag Attached: issue8
2020-09-14 15:37 rhansen Final Accepted Text => Note: 0004991
2020-09-14 15:37 rhansen Status New => Resolved
2020-09-14 15:37 rhansen Resolution Open => Accepted As Marked
2020-09-30 14:20 geoffclare Status Resolved => Applied
2024-06-11 09:12 agadmin Status Applied => Closed


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