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
0000669 [1003.1(2008)/Issue 7] System Interfaces Objection Clarification Requested 2013-03-12 00:31 2019-06-10 08:55
Reporter philip-guenther View Status public  
Assigned To ajosey
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Philip Guenther
Organization OpenBSD
User Reference
Section mkdtemp/mkstemp
Page Number 1292
Line Number 42419
Interp Status Approved
Final Accepted Text Note: 0001488
Summary 0000669: mkdtemp/mkstemp handling of template with more than 6 'X's should be clarified
Description The description of mkdtemp and mkstemp is unclear as to whether the implementation is allowed to change _more_ than 6 trailing 'X's. The current wording says:
----
The mkdtemp() function uses the contents of template to construct a unique
directory name. The string provided in template shall be a filename ending
with six trailing 'X's. The mkdtemp() function shall replace each 'X' with
a character from the portable filename character set.
----

While a template ending with seven trailing X's does also ends with six trailing 'X' (and 5, 4, 3, etc),

The reference to "each 'X'" might be read to refer to "six trailing 'X's" and therefore limit the implementation to only changing the last 6, even if there are more than 6 trailing 'X's. The wording should be changed to make it clear that an implementation may change all trailing 'X's.

(The original mkdtemp() implementation in 1997 in OpenBSD's libc would change all trailing 'X's, so this has been a possibility with mkdtemp() from before it was even standardized.)

The same goes for mkstemp(), of course.


Note that implementation are certainly not _required_ to change all the X's. Indeed, if the pathname in the unchanged template doesn't exist at the time of the call then it can create the path with all those X's and return with the template unchanged, but that's not something the application be depend upon.
Desired Action Change the second two sentences of the DESCRIPTION from this:
    The string provided in template shall be a filename ending with six
    trailing 'X's. The mkdtemp() function shall replace each 'X' with a
    character from the portable filename character set.
to
    The string provided in template shall be a filename ending with at
    least six trailing 'X's. The mkdtemp() function shall replace each
    trailing 'X' with a character from the portable filename character set.


and change this sentence:
    The string in template should look like a filename with six trailing
    'X's; mkstemp() replaces each 'X' with a character from the portable
    filename character set.
to
    The string in template shall be a filename with at least six trailing
    'X's; mkstemp() replaces each trailing 'X' with a character from the
    portable filename character set.


and (perhaps) add to the APPLICATION USAGE section:
    Since 'X' is in the portable filename character set, mkstemp() may
    leave 'X's unchanged in the template.
Tags tc2-2008
Attached Files

- Relationships

-  Notes
(0001488)
geoffclare (manager)
2013-03-12 09:45
edited on: 2013-04-11 15:44

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.

Rationale:
-------------
None.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------

After applying the TC1 edits, change:

    The string provided in template shall be a pathname ending with six
    trailing 'X's. The mkdtemp() function shall replace each 'X' with a
    character from the portable filename character set.

to:

    The application shall ensure that the string provided in template
    is a pathname ending with at least six trailing 'X's. The mkdtemp()
    function shall replace six or more 'X's at the end of the pathname
    with the same number of characters from the portable filename
    character set.

At line 42430, after applying the TC1 edits, change:

    The string in template should look like a pathname with six
    trailing 'X's; mkstemp() replaces each 'X' with a character from
    the portable filename character set.

to:

    The application shall ensure that the string provided in template
    is a pathname ending with at least six trailing 'X's. The mkstemp()
    function shall replace six or more 'X's at the end of the pathname
    with the same number of characters from the portable filename
    character set.

At line 42476 in the APPLICATION USAGE section change:

    The mkdtemp() and mkstemp() functions need not check to determine
    whether the filename part of template exceeds the maximum
    allowable filename length.

to:

    Portable applications should pass exactly six trailing 'X's in
    the template and no more; implementations may treat any
    additional trailing 'X's as either a fixed or replaceable part
    of the template. To be sure of only passing six, a fixed string
    of at least one non-'X' character should precede the six 'X's.

    Since 'X' is in the portable filename character set, some of the
    replacement characters can be 'X's, leaving part (or even all) of
    the template effectively unchanged.

(0001528)
dalias (reporter)
2013-04-01 03:59

Is there a motivation for this change? As presently specified, the behavior of these functions is very well-defined; the replacable part is defined as the last 6 bytes of the string, and to clarify the caller's intent, they must be pre-filled with 'X'. However, allowing the implementation to replace more adjacent 'X' bytes creates an unsettling ambiguity. For instance, if the application were calling mkstemp with a generated templates of the form "%sXXXXXX" where the "%s" part is (for example) a base64 token unique to a particular part of the application, the proposed changes could cause mkstemp to modify the initial token part. This in turn could cause glob() to fail to match one of the temporary files the application expects it to.
(0001532)
philip-guenther (reporter)
2013-04-05 08:29

> Is there a motivation for this change?

The motivation for this change is that modern BSD systems change all trailing X's. The repositories for NetBSD and FreeBSD show that the BSD 4.4 lite version of mktemp()**, changed all the trailing X's and in my scan I could not find an intervening version that limited itself. Do you know of any version of any BSD which _doesn't_ change all the trailing X's?

** BSD 4.4. lite was imported into NetBSD on 1993-03-21


The status of mkdtemp() is even clearer: the system which created it did not limit the number of X's changed, nor did FreeBSD or NetBSD when they adding the interface. MacOS 10.6.8 agrees with them. So if the claim is that mkdtemp() is required to change at most six trailing X's, then the specification was done in a way to render all the existing BSD implementations non-conformant, creating a false promise for applications, without any justification in the rationale or even contacting the authors to say "hey, can you explain why you didn't limit it?"


> For instance, if the application were calling mkstemp with a generated
> templates of the form "%sXXXXXX" where the "%s" part is (for example) a
> base64 token unique to a particular part of the application, the proposed
> changes could cause mkstemp to modify the initial token part.

Apparently these application have *never* been run on any modern version of BSD.

I guess such an application, which in 20 years hasn't caught and fixed this bug, should be quite happy to depend on the implementation-dependent behavior of some systems that have chosen to always replace trailing X's before the 6th with...'X's, which is perfectly conformant with the specification both now and with the proposed changes.
(0001817)
ajosey (manager)
2013-09-06 04:58

Interpretation Proposed 6 Sep 2013
(0001886)
ajosey (manager)
2013-10-14 13:04

Interpretation approved 14 October 2013

- Issue History
Date Modified Username Field Change
2013-03-12 00:31 philip-guenther New Issue
2013-03-12 00:31 philip-guenther Status New => Under Review
2013-03-12 00:31 philip-guenther Assigned To => ajosey
2013-03-12 00:31 philip-guenther Name => Philip Guenther
2013-03-12 00:31 philip-guenther Organization => OpenBSD
2013-03-12 00:31 philip-guenther Section => mkdtemp/mkstemp
2013-03-12 00:31 philip-guenther Page Number => 1292
2013-03-12 00:31 philip-guenther Line Number => 42419
2013-03-12 09:45 geoffclare Note Added: 0001488
2013-03-12 09:56 geoffclare Note Edited: 0001488
2013-03-12 14:46 geoffclare Note Edited: 0001488
2013-04-01 03:59 dalias Note Added: 0001528
2013-04-05 08:29 philip-guenther Note Added: 0001532
2013-04-11 15:43 geoffclare Note Edited: 0001488
2013-04-11 15:44 geoffclare Interp Status => Pending
2013-04-11 15:44 geoffclare Final Accepted Text => Note: 0001488
2013-04-11 15:44 geoffclare Status Under Review => Interpretation Required
2013-04-11 15:44 geoffclare Resolution Open => Accepted As Marked
2013-04-11 15:44 geoffclare Note Edited: 0001488
2013-04-11 15:47 geoffclare Tag Attached: tc2-2008
2013-09-06 04:58 ajosey Interp Status Pending => Proposed
2013-09-06 04:58 ajosey Note Added: 0001817
2013-10-14 13:04 ajosey Interp Status Proposed => Approved
2013-10-14 13:04 ajosey Note Added: 0001886
2019-06-10 08:55 agadmin Status Interpretation Required => Closed


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