Bug #18382 Updated: php looking for session_mm.sem even though session set to files
| From: | nod at bouncing dot org | Date: | Wed, 17 Jul 2002 19:05:35 +0000 |
| Subject: | Bug #18382 Updated: php looking for session_mm.sem even though session set to files | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-14443@lists.php.net to get a copy of this message | ||
ID: 18382
Updated by: nod@bouncing.org
Reported By: nod@bouncing.org
-Status: Feedback
+Status: Open
Bug Type: Session related
Operating System: suse linux 8
PHP Version: 4.2.1
New Comment:
very reproducible now, even with the latest snapshot.
first check the contents of /tmp and if it exists remove
/tmp/session_mm.sem as this is what happens on boot.
run /usr/bin/php -h as root
ls /tmp
and session_mm.sem will be there as read/ write only to root
as an unprivileged user run
/usr/bin/php -h
and it crashes. session.save_handler is set in /etc/php.ini as files.
My configure and exact error and file permission are listed below.
Surely each php session should be on a per user basis with each person
having their own .sem file ?
./configure --with-apxs --with-mysql --with-pgsql --with-mm
--enable-trans-id
-rw------- 1 root root 0 Jul 17 19:47 session_mm.sem
nod@shortnblue:/usr/src/php4-200207170900> /usr/bin/php -h
Content-type: text/html
PHP Fatal error: Unable to start session mm module in Unknown on line
0
Previous Comments:
------------------------------------------------------------------------
[2002-07-17 13:54:13] sniper@php.net
Can you please try this snapshot:
http://snaps.php.net/php4-latest.tar.gz
I can't reproduce this with the latest 4.3.0-dev..
------------------------------------------------------------------------
[2002-07-17 13:08:13] nod@bouncing.org
opening again
------------------------------------------------------------------------
[2002-07-17 13:06:52] nod@bouncing.org
bug is still open with 4.2.1
if you run /usr/bin/php as root it puts a session_mm.sem in tmp with
read write only privileges to the root user, thereby disabling other
user's ability to run. session.save_handler is still set to files, but
is still calling mm.
------------------------------------------------------------------------
[2002-07-17 01:23:06] sniper@php.net
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 http://www.php.net/downloads.php
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.
------------------------------------------------------------------------
[2002-07-16 20:47:29] nod@bouncing.org
/usr/bin/php -h
for any unprivileged user. What is happening is that the suse apache
server starts up with /tmp/session_mm.sem set to read write only for
root, therefore everyone else cannot run a php script when /usr/bin/php
is run as root it resets itself to rw for everyone, the question is
whether or not /usr/bin/php should be looking for session_mm when
sessions are disabled just because it was compiled with it.
This bug is with all versions of suse 8.0 including their latest
patched version of php and mm, and is probably quite important since
even when I upgraded and recompiled to try and solve the bug it still
happened.
Could this be left open ? since anyone using php on the command line is
going to be stuck with it. It has been reported to suse.
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=18382&edit=1