|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #55804 tempnam(): wrong fallback to /tmp
Submitted: 2011-09-28 09:05 UTC Modified: 2015-04-20 15:30 UTC
Avg. Score:3.0 ± 0.0
Reproduced:2 of 2 (100.0%)
Same Version:0 (0.0%)
Same OS:2 (100.0%)
From: spam2 at rhsoft dot net Assigned: cmb (profile)
Status: Not a bug Package: Filesystem function related
PHP Version: 5.3.8 OS: Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: spam2 at rhsoft dot net
New email:
PHP Version: OS:


 [2011-09-28 09:05 UTC] spam2 at rhsoft dot net
tempnam() should NOT fall back to /tmp if the $dir-param is explicit set to a real-path inside the open_basedir and because of wrong permissions $dir is not writeable

Test script:
 $temp_folder = dirname(__FILE__) . '/temp/';
 chmod($temp_folder, 0555);
 $tmp_name = str_replace("\\", '/', tempnam($temp_folder, 'rhcsv'));
 $fp = fopen($tmp_name, 'wb+');
  flock($fp, LOCK_EX);
  fwrite($fp, 'test');
  flock($fp, LOCK_UN);

Expected result:
error message that $dir is not writeable

Actual result:
temporary file is created in /tmp which violates open_basedir and fopen() is failing with open_basedir restriction messages


doc-55804 (last revision 2015-04-18 00:33 UTC by

Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2011-09-28 09:09 UTC]
Documented behavior, changing it will break BC.

To correctly configure the temp directory in each host is a the way to go for now.
 [2011-09-28 09:13 UTC] spam2 at rhsoft dot net
> Documented behavior, changing it will break BC

what sort of BC?
the created file is outside open_basedir, can not be used and can not be deleted
so this file is useless and simply at the wrong location
i can not imagine any code which useful relies on that "feature"
 [2011-09-28 09:14 UTC]
if the files are not removed on request or sapi shutdown, then we have a bug.
 [2011-09-28 09:22 UTC] spam2 at rhsoft dot net
they are not removed or how should a stat-call in a terminal show that they are existing? anyways - they must not be created

Warning: fopen() [function.fopen.php]: open_basedir restriction in effect. File(/tmp/rhcsv5f9RIs) is not within the
allowed path(s): (/mnt/data/www/ in
/mnt/data/www/ on line 6
Warning: fopen(/tmp/rhcsv5f9RIs) [function.fopen.php]: failed to open stream: Operation not permitted in
/mnt/data/www/ on line 6

[harry@srv-rhsoft:~]$ stat /tmp/rhcsv5f9RIs
  Datei: „/tmp/rhcsv5f9RIs“
  Größe: 0              Blöcke: 0          EA Block: 4096   reguläre leere Datei
Gerät: 809h/2057d       Inode: 48          Verknüpfungen: 1
Zugriff: (0600/-rw-------)  Uid: (   48/  apache)   Gid: (   48/  apache)
Zugriff    : 2011-09-28 08:58:01.046916064 +0200
Modifiziert: 2011-09-28 08:58:01.046916064 +0200
Geändert   : 2011-09-28 08:58:01.046916064 +0200
 [2011-09-28 09:28 UTC]
I was wrong about the removal, that's only for tmpfile.

The rest of my comment remains (BC break and easy solution).
 [2011-09-28 09:42 UTC] spam2 at rhsoft dot net
your definition of "easy solution" is a little bit strange
how can it be easy to set a ENV-Var for 500 domains where
only most of them use docroot/temp/

a smarter fallback would be the configured uploadtemp but not /tmp
 [2015-01-19 16:48 UTC] jo at feuersee dot de
May I propose to clarify the documentation then, pls? It currently reads: "If the directory does not exist, tempnam() may generate a file in the system's temporary directory, and return the full path to that file, including its name."

In fact it should hint the permission relation:
"If the directory does not exist or is not writeable ..."

And the fallback behavios should vanish in PHP7
 [2015-03-24 10:37 UTC] php at geheimeinformatie dot nl
Even without an open_basedir restriction in place, the following script:

ini_set( "error_reporting", 2047 );
ini_set( "display_errors", 1 );
var_dump( tempnam( "/etc", "wtf-" ) );

just yields the output 'string(15) "/tmp/wtf-xxxxxx"'.

There's no PHP warning, or any sort of indication that the operation failed. The only way to tell the write failed is to manually verify that the file in question is actually in the specified folder.

I *get* falling back to sensible defaults, but is a simple warning too much to ask?

I can also verify that this is indeed documented behaviour, but quite frankly I didn't start looking for this, let's face it, this *footnote* in the docs until after I bricked multiple servers. (Running out of disk space on Linux is not pretty.)
 [2015-04-18 00:33 UTC]
The following patch has been added/updated:

Patch Name: doc-55804
Revision:   1429317201
 [2015-04-18 00:35 UTC]
-Type: Bug +Type: Documentation Problem -Package: Safe Mode/open_basedir +Package: Filesystem function related
 [2015-04-18 00:35 UTC]
> I *get* falling back to sensible defaults, but is a simple
> warning too much to ask?

Even a notice might be considered a BC break.

> And the fallback behavios should vanish in PHP7

I'm afraid this ship has sailed[1].

I'm switching the issue to "Documentation Problem".

[1] <>
 [2015-04-18 05:37 UTC] php at geheimeinformatie dot nl
> Even a notice might be considered a BC break.

This is arguable at best, but I'm sure the PHP team have thought this through more often than I have.

So we can either wait for 7.1 or just roll our eyes, sigh deeply, and deal with it? Righty-oh.
 [2015-04-18 08:25 UTC] spam2 at rhsoft dot net
boah falling back to /tmp when it is not inide open_basedir() is *plain wrong* because you can not access the created file - it's hard to understand how idiotic the discussions in context of clear bugs are all the time 

 [2015-04-20 14:45 UTC]
-Status: Open +Status: Feedback -Type: Documentation Problem +Type: Bug -Assigned To: +Assigned To: cmb
 [2015-04-20 14:45 UTC]
Actually, during the discussion of this ticket there have been
raised three distinct issues:

  1) tempnam() doesn't heed open_basedir, when falling back to the
     temp dir
  2) when tempnam() falls back to the temp dir, no notice is thrown
  3) it is not well documented under which circumstances tempnam()
     falls back to the temp dir
That is always a bit unfortunate, but even more so in this case,
because 1) could be considered a bug, 2) would be a feature/change
request, and 3) is a documentation problem. Therefore I have split
2) to bug #69489 and 3) to bug #69488.

With regard to 1): I can't reproduce the behavior of the given test
script on somewhat recent versions of PHP. I get:

    Warning: tempnam(): open_basedir restriction in effect.
    File(/tmp) is not within the allowed path(s): (...) in ... on
    line 5

Is this issue still reproducable elsewhere?
 [2015-04-20 14:53 UTC] spam2 at rhsoft dot net
-Status: Feedback +Status: Assigned
 [2015-04-20 14:53 UTC] spam2 at rhsoft dot net
maybe this was fixed in the meantime

the whole bugreport was about 1) where php created files below /tmp returned that path and fopen() later failed because open_basedir and so that useless files where lying around

but anyways 2) is a bug and not a feature request because $dir is not just a wish to santa claus - falling back to somewhere else is hardly the desired result and unexpected behavior never becomes correct because someone adds it to the docs
 [2015-04-20 15:30 UTC]
-Status: Assigned +Status: Not a bug
 [2015-04-20 15:30 UTC]
Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP -- 
the problem might already be fixed. Please download a new
PHP version from

If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.

Please comment on bug #69489 in its respective ticket.
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Mon Sep 26 08:05:53 2022 UTC