Jump to content

Apache2 virtual hosts trying to share same PHP sessions


zq29

Recommended Posts

We have a dedicated server managed by our hosting company which was recently migrated from a FreeBSD/PHP4/MySQL4 box to an Ubuntu/PHP5/MySQL5 box.

 

It appears that all of the accounts on the new server, assumed to be created as virtual hosts, are all trying to share the same PHP session files. For example, I have created a basic script as follows:

 

<?php
session_start();
$_SESSION['test'] = "test";
echo $_SESSION['test'];
?>

 

Now, the first virtual host I execute the script on returns 'test' as it should, but each subsequent execution on a different virtual host returns an error like so:

 

Warning: session_start() [function.session-start]: open(/tmp/sess_3373fb7c1f4650a35d7f417419bbfd6b, O_RDWR) failed: Permission denied (13) in /home/f/o/foo/public_html/test.php on line 2

 

Warning: session_start() [function.session-start]: Cannot send session cookie - headers already sent by (output started at /home/f/o/foo/public_html/test.php:2) in /home/f/o/foo/public_html/test.php on line 2

 

Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at /home/f/o/foo/public_html/test.php:2) in /home/f/o/foo/public_html/test.php on line 2

 

Obviously the path to test.php is different on each virtual host, but the path to the session file (/tmp/sess_3373fb7c1f4650a35d7f417419bbfd6b) is the same.

 

Running ls -la /tmp points out that /tmp/sess_3373fb7c1f4650a35d7f417419bbfd6b has a uid that belongs to the first virtual host that executed the script.

 

My hosting company can't find anything wrong, and are telling me that my scripts are trying to access sessions created by other accounts, but my test script is just trying to create a session, not pick up a session previously created by another account, as you can see above.

 

Does anyone have any ideas of what I could suggest to my hosting company, or where I might be looking to solve this problem?

 

Many thanks.

Link to comment
Share on other sites

If it's a VPS you can just change up the perms of /tmp.  If not, you'll have to either get your host to change them, or use your own session path.  (Either change the ini setting [not sure if you can on the fly...] where sessions are saved, or use your own session handler.)

Link to comment
Share on other sites

This is one of our dedicated servers, I have chroot access to it. /tmp is writable by the account users, but the problem is, accounts are trying to share the same sessions when they shouldn't be. On the server we migrated from the session save path was /tmp and each account created and used its own sessions in that directory - I'm sure there must be a configuration problem somewhere...

 

There are about 50 websites on this server, rewriting the code on each of them isn't really a favorable option when it sounds like a config issue.

Link to comment
Share on other sites

That sounds weird.  The session cookie should only work for the domain on which it was created.

 

Oh, it's interesting that you say domain as my nameservers are still pointing to the old server until we're happy with the new one, so I have been accessing each account from an IP address and directory, i.e. http://123.123.123.123:81/foo/ But I have tested the same access method on our other server (http://321.321.321.321:81/bar/) and the sessions are working fine...

Link to comment
Share on other sites

I use Linux, though we use a hosts file too :)

 

I have just attributed two unused domains to the accounts, and accessing them through the domains doesn't produce the error, everything works as it should. But it should also work when accessing the accounts by the IP - I have reported my findings to my host, hopefully this might help them figure it out. Cheers for your input Corbin.

Link to comment
Share on other sites

But it should also work when accessing the accounts by the IP

 

I dont think so. http://321.321.321.321:81/foo and http://321.321.321.321:81/bar are actually refered to by the same ip address so apache thinks it safe to share the sessions.

That was my initial thought, but some how, one of our other servers appears to figure it out somehow. Not that it's an issue now that I have solved to problem, no one is going to access any of the sites by the server IP anyway...

Link to comment
Share on other sites

"That was my initial thought, but some how, one of our other servers appears to figure it out somehow. Not that it's an issue now that I have solved to problem, no one is going to access any of the sites by the server IP anyway..."

 

 

The other server probably has looser permissions on tmp.

Link to comment
Share on other sites

  • 2 weeks later...
This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.