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: http://issues.apache.org/bugzilla/show_bug.cgi?id=34869 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): httpd-2.0.46-44.ent How reproducible: Sometimes 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. <?php $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>'; mkdir($targetdir); } echo 'creating file.<hr>'; $fs = fopen($targetfile,"w"); fwrite($fs,"this is a test\n$thedate $thetime"); fclose($fs); 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:
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?
php-4.3.2-23.ent 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
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?
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 process?
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.
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: http://www.redhat.com/security/updates/errata/ 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.