Atomicorp

Hi guys.

I see you just pushed a php upgrade which was due to a CVE for security reasons.

Now there is a problem. I have built a site which was using sessions. Before the update everything was fine. After the update I simply couldn't log in ! I cheched the logs and found nothing. Then a customer contacted me who could see session errors (permission denied) and then I found out there was a session issue now.

I checked and found out a parallels kb which describes that you change the folder of session save in the control panel and you go and create under the private folder a folder for sessions which needs to have as user permissions user:psacln.
http://kb.parallels.com/en/7056

I still don't know how many have been impacted by this. But it is very strange. Both sites were working just fine just before the update !
This makes me believe the problem was caused by the php update.

Does anybody else confirm that ? Most cms wll probably not be affected since they store their sessions in database. However there are php applications that save sessions the "old way".

I really need an update from the ASL guys.


the errors were the following On the other site as I said there were zero errors. Which troubles me a lot.

Regards

On a non-.13 system:
Is this the same as yours?

Incidentally, I note the KB you linked to only applies to Plesk earlier than 10.4.

It also lists perms for the sessions directory that are different to the ones on my system.

I'm wondering if Plesk changes perms during install, and that the .13 php set them back to a default or something?

faris wrote:On a non-.13 system:

Code: Select all

# ls -al /var/lib/php/
total 1960
drwxr-xr-x  3 root root    4096 Mar  4 16:37 .
drwxr-xr-x 26 root root    4096 Apr 13 10:12 ..
drwx-wx-wt  2 root root 1994752 May  9 11:40 session

Is this the same as yours?

Incidentally, I note the KB you linked to only applies to Plesk earlier than 10.4.

It also lists perms for the sessions directory that are different to the ones on my system.

I'm wondering if Plesk changes perms during install, and that the .13 php set them back to a default or something?

Nope.
My permissions are drwxrwx--- 2 root apache 7512064 May 9 11:01 session
I will try changing the permissions now and let you know if it worked.

I have no idea how this happened. All I know is that sessions wouldn't work after the upgrade and they only worked after I did this change on the kb. It is very strange...

Yeap. Its working now. S**t. That was weird ...

Probably others will have experienced the same thing after the php upgrade. I suggest you guys take a look on that issue on your servers ...

Hello,

An older topic, but as I face the same problem I post here.

I just updated php on my Centos 5 vps from 5.2.17 to 5.3.17 from the atomic repo.

Since then I spent quite a few hours trying to figure out why some logins on some of my domains didn´t work anymore.

Thanks to this topic I found out why.

I do not want to upgrade my plesk, the kb article suggestion seems a lot of change for something that was working without a prob before the php update.

I tried to chmod the /var/lib/php/sessions folder to 777 but that was not good enough.

Is there any chance of a fix for this that doesnt involve upgrading plesk?

Thanks, greetings.

Hello,

php sessions folder has nothing to do with plesk. It only has to do with PHP. So chmod 777 this folder and do an apache restart and it should fix the login problems you are facing. Every time the php is updated from thme repository this folder needs permissions to be changed to 777. Alternatively go to php.ini set a new folder name create the new folder, make it 777 and then when php updates it will not mess up with your custom folder.

By the way Plesk 9 and 10 and 11 work fine with php 5.3.x.

Hope I helped you out.

Dogs and things wrote:Hello,

An older topic, but as I face the same problem I post here.

I just updated php on my Centos 5 vps from 5.2.17 to 5.3.17 from the atomic repo.

Since then I spent quite a few hours trying to figure out why some logins on some of my domains didn´t work anymore.

Thanks to this topic I found out why.

I do not want to upgrade my plesk, the kb article suggestion seems a lot of change for something that was working without a prob before the php update.

I tried to chmod the /var/lib/php/sessions folder to 777 but that was not good enough.

Is there any chance of a fix for this that doesnt involve upgrading plesk?

Thanks, greetings.

[root@c6-64-qa ~]# ll /var/lib/php/
total 4
drwxrwx--- 2 root apache 4096 Jul 3 12:56 session

[root@c6-64-qa ~]# rpm -q php
php-5.3.3-14.el6_3.x86_64

[root@c6-64-qa ~]# yum -y upgrade php
<snip>

[root@c6-64-qa ~]# ll /var/lib/php/
total 4
drwxrwx--- 2 root apache 4096 Sep 18 2012 session

[root@c6-64-qa ~]# rpm -q php
php-5.3.17-10.el6.art.x86_64

So no, not true. Upgrading php has no effect on the permissions on /var/lib/php/session.

Hello Scott,

If the /var/lib/php/sessions folder is set to 777 and you upgrade php then this folder will turn into mod 770.
I am sure !

scott wrote:

[root@c6-64-qa ~]# ll /var/lib/php/
total 4
drwxrwx--- 2 root apache 4096 Jul 3 12:56 session

[root@c6-64-qa ~]# rpm -q php
php-5.3.3-14.el6_3.x86_64

[root@c6-64-qa ~]# yum -y upgrade php
<snip>

[root@c6-64-qa ~]# ll /var/lib/php/
total 4
drwxrwx--- 2 root apache 4096 Sep 18 2012 session

[root@c6-64-qa ~]# rpm -q php
php-5.3.17-10.el6.art.x86_64

So no, not true. Upgrading php has no effect on the permissions on /var/lib/php/session.

Chmodding /var/lib/php/sessions to 777 and restarting Apache solved the problem, or at least it made my sessions work again.

If it hasn´t got to do with the php upgrade then maybe one of the dependencies that were installed/upgraded caused this?

This problem is fixed in the current Plesk 9/10/11 versions AFAIK: https://www.atomicorp.com/forum/viewtop ... f=2&t=5868

Mode 0770 is fine with user root and group apache.

Unfortunately we see session issues with php in fast-cgi mode with the "correct" permissions. It is very annoying. If they were 777 then it would be OK. But that would seem dangerous to me.

The most secure way to deal with sessions is to configure a custom session.save_path per site anyway. I don't know why control panels don't set this up automatically, because it would also take away the confusion when a site tries to use a custom longer session lifetime (session.gc_maxlifetime) and finds out it doesn't work (because other sites are using the same directory for their session with a shorter lifetime and wipe out session files for all domains).

It's also pretty easy to read another site's session files if they're all in the same directory.

Oh, and if you're going to configure a custom session.save_path, please make sure you don't allow the webserver to serve session files to the public (for instance via .htaccess -> Deny from all).

That's great advice. Thanks Breun.

What annoys me is:

a) There's a Plesk KB that tells you how to create a directory within the site's folder structure and use it as the session save path, then goes on to say that this isn't necessary as the bug that required it has been fixed.

b) Why doesn't the generic shared path work for php-fcgi? Or maybe I should ask why does it work for mod_php? Neither are root, both are user.group *.apache, yet only mod_php works. The Group on the folder (apache) has rwx. So I'm missing something, as usual!

faris wrote:b) Why doesn't the generic shared path work for php-fcgi? Or maybe I should ask why does it work for mod_php? Neither are root, both are user.group *.apache, yet only mod_php works. The Group on the folder (apache) has rwx. So I'm missing something, as usual!

Mode 0770, owner root and group apache works because mod_php is running code as user apache, which is in the apache group and users in the apache group are allowed to write to /var/lib/php/session. Plesk domain users are not in the apache group (nor root of course), so are indeed not be able to write to /var/lib/php/session if it's 0770 root/apache.

Ah. yes. Of course. Thanks Breun. apache is in apache, but [ftpuser] is not. I was thinking they were, but of course that wouldn't be right.