When I let PHP scripts run as a Siteworx user, session aren?t working. When I let them run as Apache sessions work fine.
It sounds like PHP is unable to write session data because of directory permissions. Check to make sure that /var/lib/php/session is readable/writable by SiteWorx user shell accounts.
Another option would be to configure PHP to use MySQL as the session save handler in the php.ini file.
I have the same issue. How to I set it so that it is writeable by interworx user accounts? Or even mysql in php.ini?
Please advice.
Thanks
chmod -R 777 /var/lib/php/session
I’d highly advise against setting it 777, because that means that anybody can read/write data to that directory (security risk). Sessions in suPHP have always been a bit of a tricky issue.
The true “right” way (imo) to do this would be to create a php/session directory in /home/username/var/domainname/lib and configure each web application to put it’s session data there. Unfortunately this would have to be done manually for each SiteWorx account.
Again, I’d advise setting MySQL as the session handler (or memcached, in the case of a few of my sites).
the files are created with limited permissions.
-rw------- 1 finalong finalong 224 Jun 15 18:23 sess_rphbs5poasg1k925o9itqmerj0
-rw------- 1 finalong finalong 58 Jun 15 18:06 sess_s51sekuoc9dqigg3450n8tuku4
-rw------- 1 finalong finalong 219 Jun 15 18:27 sess_s69u0n6353jpsvhfpft2mudbu1
-rw------- 1 finalong finalong 214 Jun 15 18:16 sess_s9rrjpa73vuhj4bjt5k2co13c2
-rw------- 1 finalong finalong 75 Jun 15 18:24 sess_sf0h62v322j3saluams2o81mg5
-rw------- 1 finalong finalong 227 Jun 15 18:22 sess_smlb7q942aahhusah5af850ob0
-rw------- 1 finalong finalong 58 Jun 15 18:24 sess_snj2g544g4ej5muep064mvhdu0
-rw------- 1 finalong finalong 58 Jun 15 18:15 sess_staak9ai9lrq8ee9q8bmcf0q21
-rw------- 1 finalong finalong 220 Jun 15 18:25 sess_t0501j5d7s63vhv46i0u8aaap4
-rw------- 1 finalong finalong 221 Jun 15 18:05 sess_t0jg4rd2d26b7vc9orlc7p9e81
-rw------- 1 finalong finalong 58 Jun 15 18:32 sess_t1lilr4o829em8nkof8v1g0nv7
-rw------- 1 finalong finalong 58 Jun 15 18:33 sess_t711jue6ar23lap0a4k4cg7oi6
-rw------- 1 finalong finalong 58 Jun 15 18:11 sess_tan9tjvueks18tovmcquoc0k37
-rw------- 1 finalong finalong 58 Jun 15 18:06 sess_tedlqvqc5natu7a9hrjs7kocg6
-rw------- 1 finalong finalong 58 Jun 15 18:30 sess_tf53plgkc5fv4o3332b212gci3
-rw------- 1 finalong finalong 58 Jun 15 18:34 sess_th8rtv9ip4ptdvel8h9hlodi87
-rw------- 1 finalong finalong 58 Jun 15 18:05 sess_tm7otpa3iaaloj9ddbgukdd2i3
-rw------- 1 finalong finalong 58 Jun 15 18:24 sess_toorrju2rvoee72ut8qnisbp25
-rw------- 1 finalong finalong 58 Jun 15 18:33 sess_tqb4748ftrqk70ptism1e82j16
-rw------- 1 finalong finalong 90 Jun 15 18:18 sess_u1m8gpou5fohu0ea6b1tjmdl54
there shouldn’t security problems.
maybe I’m reasoning wrong?
edit:
I understand what do you mean about security?. I changed the chmod 777 to 333 and now it works very well.
d-wx-wx-wx 2 root apache 45056 Jun 15 19:28 session
Now, althrough siteworx users are able to create and read sessions, it is not anymore possible to list the directory.
Or just write your own session class. Use a cookie and a mysql database table, that’s the way I’ve done it for like 8 years now.
[QUOTE=darknet;17214]
I understand what do you mean about security?. I changed the chmod 777 to 333 and now it works very well.
d-wx-wx-wx 2 root apache 45056 Jun 15 19:28 session
Now, althrough siteworx users are able to create and read sessions, it is not anymore possible to list the directory.[/QUOTE]
Fair enough. As long as the directory is not able to be listed by non-authorized users then there shouldn’t be too much of a problem. My fear was that a malicious user could find a cli injection bug in a poorly-coded web-app, list the contents of /tmp, and then potentially steal a user’s session (again, because of a poorly coded web-app).
Don’t mind me, having a super paranoid security mindset is just part of being a control-panel developer.
Thanx! This helped me allot 
chmod -R 333 /var/lib/php/session
Thanks for this info!
That said, when I looked, the perms were 770, so would 773 be any more of a risk than 333? I can’t say I actually understand the implications of different perms on the dir, other than if “other” doesn’t have write perms in this case, no session files can be written by users. Is there no case in which root or apache (owner and group on my install) would need to list the dir?
i had the same problem and fixed it intsalling memcached. on centos simply type
yum install memcached
yum install php-pecl-memcached
and edit in the php.ini file the following lines:
session.save_handler = memcached
session.save_path = “localhost:11211”
start memcached and restart apache and it should work