| problem with session cleanup [message #170137] |
Tue, 12 October 2010 11:25  |
bill
Messages: 310
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
occasionally when I use an application I am developing I get the
following error:
Notice: session_start() [function.session-start]:
ps_files_cleanup_dir: opendir(/var/lib/php5) failed: Permission
denied (13) in /var/www/MP2010-v2/challenge.php on line 2
This started when I upgraded Ubuntu from relase 9.10 to 10.04.
my directory has the following permissions
drwx-wx-wt 2 root root 4096 2010-10-12 07:19 php5
First question: what is wrong and how do I fix it.
2nd question: what is a t for other execute permission ?
bill
|
|
|
|
| Re: problem with session cleanup [message #170138 is a reply to message #170137] |
Tue, 12 October 2010 11:28  |
bill
Messages: 310
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
On 10/12/2010 7:25 AM, bill wrote:
> occasionally when I use an application I am developing I get the
> following error:
> Notice: session_start() [function.session-start]:
> ps_files_cleanup_dir: opendir(/var/lib/php5) failed: Permission
> denied (13) in /var/www/MP2010-v2/challenge.php on line 2
>
> This started when I upgraded Ubuntu from relase 9.10 to 10.04.
>
> my directory has the following permissions
> drwx-wx-wt 2 root root 4096 2010-10-12 07:19 php5
>
> First question: what is wrong and how do I fix it.
> 2nd question: what is a t for other execute permission ?
>
> bill
the answer to the 2nd question is that this is a "restricted
deletion flag. Seems right.
bill
|
|
|
|
| Re: problem with session cleanup [message #170140 is a reply to message #170138] |
Tue, 12 October 2010 12:40 |
Erwin Moller
Messages: 228
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 10/12/2010 1:28 PM, bill wrote:
> On 10/12/2010 7:25 AM, bill wrote:
>> occasionally when I use an application I am developing I get the
>> following error:
>> Notice: session_start() [function.session-start]:
>> ps_files_cleanup_dir: opendir(/var/lib/php5) failed: Permission
>> denied (13) in /var/www/MP2010-v2/challenge.php on line 2
>>
>> This started when I upgraded Ubuntu from relase 9.10 to 10.04.
>>
>> my directory has the following permissions
>> drwx-wx-wt 2 root root 4096 2010-10-12 07:19 php5
>>
>> First question: what is wrong and how do I fix it.
>> 2nd question: what is a t for other execute permission ?
>>
>> bill
>
> the answer to the 2nd question is that this is a "restricted deletion
> flag. Seems right.
>
> bill
Hi Bill,
Probably that happens because the user that runs PHP (via Apache)
doesn't have the rights to list the contents of /var/lib/php5.
I expect it will happen every request if you change the values for
session cleanup in php.ini.
; Define the probability that the 'garbage collection' process is started
; on every session initialization.
; The probability is calculated by using gc_probability/gc_divisor,
; e.g. 1/100 means there is a 1% chance that the GC process starts
; on each request.
session.gc_probability = 1
session.gc_divisor = 100
If you set them both to, say, 100: do you get that error every time?
I expect you will.
If so, that means PHP is unable to remove old session files.
If you don't fix it eventually your harddisk will flood over. ;-)
About your directory setting:
I thought that 't' was called sticky bit. (It will appear as 's' or 'S'
in owner or group column.)
I am not sure why your system is set up like that.
What you want is this:
Have a session directory that is:
- readable (listable) and
- writable (and thus deletable)
for the relevant user.
The relevant user is the one that your webserver (apache) uses.
On most systems that user is called 'www-data' or 'apache'. (I also saw
'nobody' a few times.)
How to fix it?
Disclaimer: I have no clue WHY your system is set up like that. Possibly
there is a some good reason I am unaware of. But since this isn't
working I doubt it is a good reason. ;-)
Maybe ask in an Ubuntu forum?
This is how I set up my rights on session storage directories:
[Assuming user www-data]
d rwx --- --- www-data www-data mysessionstoragedir
So that is full rights for the owner www-data on the sessiondir.
Hope this helps.
Regards,
Erwin Moller
--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare
|
|
|
|
| Re: problem with session cleanup [message #170154 is a reply to message #170140] |
Wed, 13 October 2010 06:54 |
gordonb.sp7wo
Messages: 1
Registered: October 2010
Karma: 0
|
Junior Member |
|
|
> About your directory setting:
> I thought that 't' was called sticky bit. (It will appear as 's' or 'S'
> in owner or group column.)
The so-called "sticky" bit was originally named because of its
effect on executable programs, making them hang around in memory
("please cache this"). More recently, it has another use for
directories, and the original use for executable files is obsolete,
or removed entirely.
According to the FreeBSD manual pages: "A file in a sticky directory
may only be removed or renamed if the user has write permission for
the directory and the user is the owner of the file, the owner of
the directory, or the super user." This behavior is also common
to most Unix versions and Linux.
> I am not sure why your system is set up like that.
This is a reasonable setup for a temporary directory where (a)
anyone can create files, (b) anyone can delete *his own* files, (c)
snooping on other people's files is discouraged by not being able
to list them, and even if you do, you can't rename or delete them.
(Hopefully the file permissions also prohibit reading and writing
them). It also means you can't list *your own* files. Convenience
vs. security. /tmp on FreeBSD is by default mode 1777, which allows
listing files, yours and everyone else's.
Suggested fixes (pick one or more), as the poster I'm following up
suggested:
- Make the owner of the directory the user that PHP (and Apache) runs as.
e.g. chown apache session_dir
- Put back read permission for everyone
e.g. chmod 1777 session_dir
There's minimal but not zero security risk by leaking file names,
owners (mostly PHP's user anyway), and sizes of files.
- If this directory is used *only* for session data and there is
no reason for other users to access it (such as site owners using
FTP under their own user id, or CGIs running under Apache's suexec),
make it owned by the user that PHP runs as and accessable only
by that user
e.g. chown apache session_dir; chmod 700 session_dir
> What you want is this:
> Have a session directory that is:
> - readable (listable) and
> - writable (and thus deletable)
> for the relevant user.
> The relevant user is the one that your webserver (apache) uses.
> On most systems that user is called 'www-data' or 'apache'. (I also saw
> 'nobody' a few times.)
>
> How to fix it?
> Disclaimer: I have no clue WHY your system is set up like that. Possibly
> there is a some good reason I am unaware of. But since this isn't
> working I doubt it is a good reason. ;-)
For /tmp, but *not* a session directory, many shell scripts create
files there and delete them by name (.e.g /tmp/$$.tmp, where $$ is
substituted by the shell as the process id, so two shell scripts will
use unique names), they don't need to list the names in /tmp. On
the other hand, a script writer can't tell if he's forgetting to delete
one of the temporary files.
> Maybe ask in an Ubuntu forum?
>
> This is how I set up my rights on session storage directories:
> [Assuming user www-data]
>
> d rwx --- --- www-data www-data mysessionstoragedir
>
> So that is full rights for the owner www-data on the sessiondir.
Looks good to me.
/tmp makes a lousy session directory. Having it as a default makes
sense only because it's one of a few directories you can count on
actually existing. Also, if PHP's probabalistic deletion isn't
getting rid of stale data fast enough, a stopgap shell script run
from cron to get rid of anything older than, say, 2 weeks can make
sure it's gone, without having to figure out whether it's a session
or something else.
|
|
|
|
| Re: problem with session cleanup [message #170156 is a reply to message #170137] |
Wed, 13 October 2010 08:10 |
alvaro.NOSPAMTHANX
Messages: 277
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
El 12/10/2010 13:25, bill escribió/wrote:
> occasionally when I use an application I am developing I get the
> following error:
> Notice: session_start() [function.session-start]: ps_files_cleanup_dir:
> opendir(/var/lib/php5) failed: Permission denied (13) in
> /var/www/MP2010-v2/challenge.php on line 2
>
> This started when I upgraded Ubuntu from relase 9.10 to 10.04.
>
> my directory has the following permissions
> drwx-wx-wt 2 root root 4096 2010-10-12 07:19 php5
>
> First question: what is wrong and how do I fix it.
> 2nd question: what is a t for other execute permission ?
If I recall correctly, Ubuntu disables the PHP builtin session cleanup.
Instead, it relies on a shell script that runs via cron with root
credentials. That's why no one else but root is allowed to write into
/var/lib/php5.
You need to make sure that the built-in cleanup remains disabled. Find
the "session.gc_probability" directive in your php.ini file and set it
to zero.
--
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]