php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #18382 php looking for session_mm.sem even though session set to files
Submitted: 2002-07-16 20:47 UTC Modified: 2002-07-18 02:34 UTC
From: nod at bouncing dot org Assigned:
Status: Closed Package: Session related
PHP Version: 4.3 OS: suse linux 8
Private report: No CVE-ID: None
View Developer Edit
 [2002-07-16 20:47 UTC] nod at bouncing dot 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.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-07-17 01:23 UTC] 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-17 13:06 UTC] nod at bouncing dot 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 13:08 UTC] nod at bouncing dot org 
opening again
 [2002-07-17 13:54 UTC] 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 15:05 UTC] nod at bouncing dot org 
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
 [2002-07-17 20:07 UTC] sniper@php.net 
I don't think you're trying with the correct PHP binary
now..if you would be using the snapshot (the url I posted)
the filenames would be something like these:
 
/tmp/session_mm_cgi0.sem
/tmp/session_mm_cgi501.sem 
/tmp/session_mm_cli0.sem 
/tmp/session_mm_cli501.sem

Each user id has own sem file. And each SAPI also.
Make sure you're REALLY using the correct binary,
by running 'php -v' which should show '4.3.0-dev' as version.
 [2002-07-18 02:34 UTC] nod at bouncing dot org 
you're right, /usr/bin/php is version 4.1, 4.3 installs in /usr/local/bin/php and works.
 
PHP Copyright © 2001-2026 The PHP Group
All rights reserved. 		Last updated: Wed Oct 07 11:00:02 2026 UTC