problem with session cleanup

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
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 ?


Re: problem with session cleanup

On 10/12/2010 7:25 AM, bill wrote:
Quoted text here. Click to load it

the answer to the 2nd question is that this is a "restricted
deletion flag.  Seems right.


Re: problem with session cleanup

On 10/12/2010 1:28 PM, bill wrote:
Quoted text here. Click to load it

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.

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

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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
- 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

Quoted text here. Click to load it

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.  

Quoted text here. Click to load it

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

El 12/10/2010 13:25, bill escribió/wrote:
Quoted text here. Click to load it

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

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.

-- - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web:
-- Mi web de humor satinado:

Site Timeline