ID: 31323
Comment by: prikid at gmail dot com
Reported By: julien dot mathieu at gmail dot com
Status: No Feedback
Bug Type: Session related
Operating System: Linux
PHP Version: 5.1.2, 4.3.9
New Comment:
We are experiencing similar problem with php 5.2.6 on freebsd and red
hat linux
Previous Comments:
------------------------------------------------------------------------
[2008-08-12 16:21:03] linus dot norton at assertis dot co dot uk
I have also encountered this twice on redhat running apache 2.2.6 and
php 5.2.6.
Why has this been closed, no feedback was requested then the ticket is
just closed saying no feedback has been given.
------------------------------------------------------------------------
[2006-11-09 14:44:35] mg at iceni dot pl
I can confirm this bug happening on php 4.4.2 build as apache 2 (with
prefork) module. It's extremaly difficult to reproduce, but with little
research it seems to be somehow umask related.
The following is from strace running on a apache process that creates
the files with wrong permissions
open("/tmp/sess_5b2929b94cf141335d0b2d1e5a38fc29", O_RDWR|O_CREAT,
0600) = 186
fstat64(186, {st_mode=S_IFREG|0400, st_size=0, ...}) = 0
So php creates file with 600 permissions but it has only 400 in final.
Note that's happening very rarely, normally file is created with 600.
I didn't have luck tracing how and when umask is changing during
request processing (probably something is changing it prior to the
request, so possibly it's not even php related), but I tried to make the
following very dirty workaround in ext/session/mod_files.c:
------------------------------------------------
@@ -138,6 +138,7 @@
static void ps_files_open(ps_files *data, const char *key TSRMLS_DC)
{
char buf[MAXPATHLEN];
+ mode_t orig_mask;
if (data->fd < 0 || !data->lastkey || strcmp(key,
data->lastkey)) {
if (data->lastkey) {
@@ -156,8 +157,10 @@
data->lastkey = estrdup(key);
+ orig_mask = umask(0);
data->fd = VCWD_OPEN_MODE(buf, O_CREAT | O_RDWR |
O_BINARY, 0600);
-
+ umask(orig_mask);
+
------------------------------------------------
No matter how ugly it is - it seems to do the job and session files
with wrong permissions are no longer created (this workaround is
probably bad idea on threaded severs though).
------------------------------------------------------------------------
[2006-11-05 00:16:32] bclaydon at volved dot com
To provide further details, I am also using Debian (Sarge) with the
latest 4.3.10-16 PHP4 package.
My /var/liv/php4 looks exactly as 'pieter at q-go dot com' mentioned:
drwx-wx-wt 2 root root 4.0K 2006-11-04 18:58 ./
drwxr-xr-x 35 root root 4.0K 2006-09-08 19:11 ../
-rw------- 1 www-data www-data 77 2006-11-04 18:58
sess_7b8da94a2febce75775d9082cd20d58d
-rw------- 1 www-data www-data 116 2006-11-04 19:05
sess_856401c969cc1d4e68b6ffd75457c743
-rw------- 1 www-data www-data 116 2006-11-04 18:58
sess_b5419618a3586b7e3b940a0eaf137fb9
-rw------- 1 www-data www-data 116 2006-11-04 19:09
sess_f7d957b726ff923b4b1f6178f8db489f
I am seeing this issue fairly frequently during usage of CakePHP
framework which has fairly detailed usage of session functions.
I hope this is resolved at some point, especially if it is still open
as of 5.2.0
------------------------------------------------------------------------
[2006-05-22 09:20:29] pieter at q-go dot com
We have similar problems on Debian with PHP 5.1.2 and 5.1.4.
Sessions are all created with correct permissions, but we get the same
permission denied error in 5% of the cases.
drwx-wx-wt 2 root root 4096 May 22 11:03 .
drwxr-xr-x 27 root root 4096 May 18 13:44 ..
-rw------- 1 www-data www-data 0 May 22 11:03
sess_11f06ca5b4701f4be8be30b275e4e51e
-rw------- 1 www-data www-data 1569 May 22 11:00
sess_1856e3c4630f074a1b0490c4792c3e53
-rw------- 1 www-data www-data 0 May 22 10:21
sess_d110fb48e440d1ec4ac610243e897c69
-rw------- 1 www-data www-data 1717 May 22 11:05
sess_f9668179e8a92714f4d9553504bdcd93
Changing the default Debian permissions on /var/lib/php5 from
drwx-wx-wt to drwxrwxrwt seems to help.
I am putting this here because if the two cases are related, the
problem might be more general.
------------------------------------------------------------------------
[2006-03-28 13:15:10] m...@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/31323
--
Edit this bug report at http://bugs.php.net/?id=31323&edit=1
