Achievo/ATK - Bugzilla – Bug 329
Session File Permission Changes
Last modified: 2004-09-01 23:59:15
You need to log in before you can comment on or make changes to this bug.
I receive the following error when I log out and log back into achievo: error: [@10:46:10h] [2] session_start(): open (/tmp/sess_1ff51102d3f2cfd0e0adf48a9be886ce, O_RDWR) failed: Permission denied (13) in /usr/local/apache/htdocs/achievo- 1.1.rc1/atk/session/class.atksessionmanager.inc (line 17) This error occurs after I have had the browser open for a few minutes or so. I have run chmod -R 1777 on /tmp and umask is 022, yet the session file saves as 600. After the browser has been open for about five minutes, my session is destroyed. I can no longer log back into achievo using the same browser and I receive the 13 error from apache. The session file has been changed to 400. It appears this problem occurred after I migrated to 1.1.rc1. I have tried many values for session.gc_maxlifetime from 10 to 28880 without success. I have also changed the session_gc probablilies ranging from 1/1 to 1/1000 without much effect. As an temporary solution I have enabled cookies but the error message still appears. The following is the screen dump of /tmp. -r-------- 1 nobody 4294967295 0 Aug 4 13:04 sess_ce66bc31349ae99df377d165d37dadc8 -r-------- 1 nobody 4294967295 0 Aug 4 11:46 sess_e5c45a4dbbf5ee2696e209d1939a5d00 -rw------- 1 nobody 4294967295 132 Aug 4 12:46 sess_e98fdf2207571f9a1a82e33dcd277a22 -rw------- 1 nobody 4294967295 252 Aug 4 12:41 sess_ff82acc032f4c73d5c5eb87f0dcb8597
I created an apache user and group on SuSE SLES 8.0 and switched from the nobody user and group #-1 in httpd.conf. Session creation and destruction seems to work after this change.
Possible addition to the installation notes: The default apache user and group (nobody and Group #-1) should be changed for some Linux distributions. A new user and group should be created and set to the User and Group directives in httpd.conf.
Possible Change to FAQ: 1.2. I have installed Achievo, and I am getting the following error: "Warning: open(/tmp\sess_22a61bffada1208843753014b4d6f0ac, O_RDWR) failed: No such file or directory (2) in c:\path_to_achievo\atk\session\class.atksessionmanager.inc on line 14" (or something very similar) This could be caused by two things, either of which is a PHP misconfiguration: - the session.save_path directory in php.ini is set to a directory that doesn't exist, or - the dir pointed to by session.save_path is not readable and writable by the webserver. ----Addition--- - the default apache user and group (nobody and Group #-1) should be changed for some Linux distributions. A new user and group should be created and set to the User and Group directives in httpd.conf.
Thanks for the addtion. However, just changing the user might be a bit vague. Is it possible for you to detect the differences between the 2 users between which you switched? Also, what were the permissions of the /tmp dir itself?
I am running SuSE SLES 8.0 2.1.19 kernal, PHP 4.3.5 and Apache 2.0.49. 1. The /tmp directory was set to 1777. 2. In /tmp with the apache server processes running as nobody user and group #- 1, the session file permission changed from 600 to 400 after an interval of twenty minutes or so. There is a warning in apache httpd.conf that mentions that some kernals refuse to set setgid or IPCISET if the GID is above 60000. The GID was above 60000 when the group was set to #-1. 3. Instead of leaving the default nobody user and group #-1 settings for apache, I created an apache user on SuSE and with the contents of /etc/skel copied to /home/apache. I then created an apache group and added the apache user to this group. Then, I changed httpd.conf in apache. 4. I set the user directive to apache and the group directive to apache from the default nobody user and group #-1. I restarted the apache server. After this change, I no longer received the 13 permission error.
I would like to add that /tmp was originally at root.root 1777. I changed the owner to nobody.nobody but this had no affect on the problem.
I've added your text (including a reference to this bugzilla entry for those who need more information) to the FAQ. Thanks again.