Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be unavailable on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 157648 - Intermittent 0000 Modes in Apache-Created Files
Summary: Intermittent 0000 Modes in Apache-Created Files
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: httpd
Version: 3.0
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Joe Orton
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-05-13 13:32 UTC by Brian Spolarich
Modified: 2008-04-09 18:29 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-10-19 19:02:24 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Brian Spolarich 2005-05-13 13:32:09 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1

Description of problem:
This was reported to the Apache folks as:

I've seen an intermittent problem in the modes on files that are created by programs running under apache.  This was initially evidenced in RT (www.bestpractical.com/rt), which is a Perl/Mason application, then noticed in my custom code, which is PHP4.  Usually the permissions on files created by the web server is apache:apache 0644.  Occasionally instead I get apache:apache 0000.  Directories are normally 0755, but sometimes get created as 0000 as well.  This causes applications to break, since they assume that the files/dirs they create will be readable at some point in the future. :-)

In working with my hosting provider (Rackspace) they felt it must be caused by the custom code.  So I created a simple test case (included below) to see if I could reproduce the problem without pointing a finger at my custom code.  The test harness (which simple creates directories and files in /tmp/apachetest using the current datetime) exercises the problem as well: usually the files are created with the expected permissions, but not always.

The Apache folks feel that this is either a custom code issue, or a problem with the patched release of Apache included in RHEL.

A developer I am working with is using a very different environment (OSX 10.3, Apache 2.0.52, PHP5) and having similar problems with PHP session files in /tmp/ getting intermittent bad permissions, so I thought that this was likely an Apache problem, but the Apache folks are punting back to RedHat at the moment.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.  mkdir /tmp/apachetest ; chmod 777 /tmp/apachetest
2.  Put the following script somewhere apache can execute it.
3.  Execute the script via wget, lynx -dump, etc. via cron every 15 minutes.
4.  Check out the permissions on the created files over time.


$basedir = "/tmp/apachetest";

$thedate = date("Ymd");
$thetime = date("His");

$targetdir = $basedir.'/'.$thedate;
$targetfile = $targetdir.'/'.$thetime.'.test';

echo 'targetdir: ' . $targetdir . '<hr>';
echo 'targetfile: ' . $targetfile . '<hr>';

if (!is_dir($targetdir)) {
        echo 'mkdir: '.$targetdir.'<hr>';

echo 'creating file.<hr>';

$fs = fopen($targetfile,"w");
fwrite($fs,"this is a test\n$thedate $thetime");

echo 'success.<hr>';


Actual Results:  Permissions on created files in /tmp/apachetest are:

474509    4 -rw-r--r--   1 apache   apache         30 May 13 01:16 ./20050513/011651.test
474510    4 ----------   1 apache   apache         30 May 13 01:31 ./20050513/013150.test
474511    4 ----------   1 apache   apache         30 May 13 01:46 ./20050513/014650.test
474512    4 -rw-r--r--   1 apache   apache         30 May 13 02:01 ./20050513/020150.test
474513    4 -rw-r--r--   1 apache   apache         30 May 13 02:16 ./20050513/021651.test
474514    4 -rw-r--r--   1 apache   apache         30 May 13 02:31 ./20050513/023150.test
474515    4 -rw-r--r--   1 apache   apache         30 May 13 02:46 ./20050513/024650.test
474516    4 ----------   1 apache   apache         30 May 13 03:01 ./20050513/030151.test
474517    4 ----------   1 apache   apache         30 May 13 03:16 ./20050513/031650.test
474518    4 ----------   1 apache   apache         30 May 13 03:30 ./20050513/033000.test
474519    4 -rw-r--r--   1 apache   apache         30 May 13 03:31 ./20050513/033150.test

Expected Results:  All files should have had mode=0644.

Additional info:

Comment 1 Joe Orton 2005-05-13 13:42:22 UTC
Can you confirm what version of the PHP package you are using, "rpm -q php"?

As per my comment upstream:

Do you have any PHP code which manipulates the umask of the process? Similarly,
any Perl code if you are running any in-process via mod_perl? 

Comment 2 Brian Spolarich 2005-05-13 13:58:41 UTC

If we focus on the test case, it is not manipulating the the umask of the process.  

RT 3.4.0 is running in-process in ssl.conf:
PerlModule Apache::DBI
PerlRequire /opt/rt3/bin/webmux.pl

Comment 3 Joe Orton 2005-05-13 14:08:16 UTC
The test case, this one PHP script, may not be manipulating the umask.  But you
do have other scripts running on this server, which may be requested during the
test period?  These could be changing the umask of a child process independently
of the test script.

If you look at the access_log for the period between a "good" state and a "bad"
state, are any requests made to other scripts?

To confirm this is a umask-related issue, can you add a call like "umask(0022);"
to the beginning of the test case script?

Comment 4 Brian Spolarich 2005-05-13 14:15:31 UTC
To minimize variables here, I am going to 1) upgrade RT to 3.4.2 and 2) change
it to a FastCGI-invoked application instead of the in-process stuff.  Either the
problem will go away, or I'll have something less that we can point fingers at.

Are you saying that any random PHP program could modify the umask of the apache

Comment 5 Joe Orton 2005-05-13 14:19:06 UTC
Later versions of PHP will save and restore the umask across script invocation,
but not the version in RHEL3.  (That doesn't help if it's something other than a
PHP script which is changing the umask, of course)

But yes, in RHEL3, any random PHP script running in-process can change the umask.

Comment 6 RHEL Program Management 2007-10-19 19:02:24 UTC
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
For more information of the RHEL errata support policy, please visit:
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.

Note You need to log in before you can comment on or make changes to this bug.