Need your advice on php5 session files - [Fwd: Bug#479905: phpgroupware-0.9.16-core-base: /var/lib/phpgroupware/sessions grows as files are never purged]

[Olivier Berger]

Hello.

I'm considering the right way to manage the PHP session files on
standard installations in Debian.

Maybe you can help, as I'm not really expert in PHP.

In Debian's default configuration, phpGroupware uses session files, and
the session.save_path is directed to a specific directory, separate from
the PHP5 default (/var/lib/phpgroupware/sessions instead of the
default /var/lib/php5/ in Debian).

I guess such a separate dir was a way to prevent collision with other
applicatons which may lead to security issues as phpGroupware sessions
may contain sensitive information.

Would this be a big risk to store them in the same place as other PHP
apps installed on the same server ?

Would you recommend any policy ?

You'll find bellow a bug-report about these files not being purged ATM
in Debian, btw ;)

Thanks in advance for your insights.

Best regards,
-------- Message transféré --------
De: Olivier Berger <***@it-sudparis.eu>
Répondre à: Olivier Berger <***@it-sudparis.eu>,
***@bugs.debian.org
À: ***@bugs.debian.org
Sujet: Bug#479905:
phpgroupware-0.9.16-core-base: /var/lib/phpgroupware/sessions grows as
files are never purged
Date: Wed, 07 May 2008 11:20:21 +0200

Since the re-definition of the sessions save path into phpgroupware's own dirs session files are no longer saved into php5-common's dir, and are thus not purged by the php5-common cron job.
This leads potentially to the progressive fill-up of the disk, although at a quite slow pace.
This needs to be fixed.
Btw, it must have been happening also on epoch 0 packages back when php4 was used (on sarge, etch ?) when the custom php.ini parameters were applied... but apparently noone noticed.

(responding to myself)

I'm a bit doubtful about the correct was to handle this.

It's obviously possible to add a crontab like php5-common's one.

But in the end, I'm not so sure it's best to keep sessions apart from
php5's defaults in Debian.

I can see some security assumptions about doing so... but I'm not so
sure it's really necessary. There may be a Debian policy for that ?

I'll try and ask upstream and also to other php5 maintainers maybe...

Regards,

[Chris Weiss]

On Wed, May 7, 2008 at 5:15 AM, Olivier Berger

Post by Olivier Berger
Hello.
I'm considering the right way to manage the PHP session files on
standard installations in Debian.
Maybe you can help, as I'm not really expert in PHP.
In Debian's default configuration, phpGroupware uses session files, and
the session.save_path is directed to a specific directory, separate from
the PHP5 default (/var/lib/phpgroupware/sessions instead of the
default /var/lib/php5/ in Debian).
I guess such a separate dir was a way to prevent collision with other
applicatons which may lead to security issues as phpGroupware sessions
may contain sensitive information.
Would this be a big risk to store them in the same place as other PHP
apps installed on the same server ?
Would you recommend any policy ?
You'll find bellow a bug-report about these files not being purged ATM
in Debian, btw ;)

it's always been my impression that php's garbage collection, not a
cron job, handles removing old session files. maybe what we have a
bug in php itself...

[Dave Hall]

Post by Chris Weiss
On Wed, May 7, 2008 at 5:15 AM, Olivier Berger

Post by Olivier Berger
Hello.
I'm considering the right way to manage the PHP session files on
standard installations in Debian.
Maybe you can help, as I'm not really expert in PHP.
In Debian's default configuration, phpGroupware uses session files, and
the session.save_path is directed to a specific directory, separate from
the PHP5 default (/var/lib/phpgroupware/sessions instead of the
default /var/lib/php5/ in Debian).
I guess such a separate dir was a way to prevent collision with other
applicatons which may lead to security issues as phpGroupware sessions
may contain sensitive information.
Would this be a big risk to store them in the same place as other PHP
apps installed on the same server ?
Would you recommend any policy ?
You'll find bellow a bug-report about these files not being purged ATM
in Debian, btw ;)

it's always been my impression that php's garbage collection, not a
cron job, handles removing old session files. maybe what we have a
bug in php itself...

In Debian it is a cron job. See below

I recommend a separate directory, just for security, but it probably
doesn't provide much benefit, cos if you can read the session files you
can read the header.inc.php, and so get the dd access credentials.

I am happy enough to use the common session path if that is easier for
you (and Debian).

Cheers

Dave

$ cat /etc/cron.d/php5
# /etc/cron.d/php5: crontab fragment for php5
# This purges session files older than X, where X is defined in seconds
# as the largest value of session.gc_maxlifetime from all your php.ini
# files, or 24 minutes if not defined. See /usr/lib/php5/maxlifetime

# Look for and purge old sessions every 30 minutes
09,39 * * * * root [ -x /usr/lib/php5/maxlifetime ] &&
[ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin
+$(/usr/lib/php5/maxlifetime) -print0 | xargs -r -0 rm

[Olivier Berger]

Hi.

Just for the records, I'm uploading now a new package for Debian (-5),
which will include a crontab to purge files older than 1 hour (the
default sessions expiration delay in Debian package).

We keep files in a separate dir so that Admin / View sessions works
(cause the patch fixing bug https://savannah.gnu.org/bugs/?23386 is
included too ;) by browsing the directory, and stick to a crontab so
that we don't differ too much from PHP5... the GC stuff may be
interesting, but we may use it someday if PHP5 packages in Debian do so
also by default (ne need to test new features).

Thanks for your help, guys.

Best regards,

Post by Dave Hall

Post by Chris Weiss
On Wed, May 7, 2008 at 5:15 AM, Olivier Berger

Post by Olivier Berger
Hello.
I'm considering the right way to manage the PHP session files on
standard installations in Debian.
Maybe you can help, as I'm not really expert in PHP.
In Debian's default configuration, phpGroupware uses session files, and
the session.save_path is directed to a specific directory, separate from
the PHP5 default (/var/lib/phpgroupware/sessions instead of the
default /var/lib/php5/ in Debian).
I guess such a separate dir was a way to prevent collision with other
applicatons which may lead to security issues as phpGroupware sessions
may contain sensitive information.
Would this be a big risk to store them in the same place as other PHP
apps installed on the same server ?
Would you recommend any policy ?
You'll find bellow a bug-report about these files not being purged ATM
in Debian, btw ;)

it's always been my impression that php's garbage collection, not a
cron job, handles removing old session files. maybe what we have a
bug in php itself...

In Debian it is a cron job. See below
I recommend a separate directory, just for security, but it probably
doesn't provide much benefit, cos if you can read the session files you
can read the header.inc.php, and so get the dd access credentials.
I am happy enough to use the common session path if that is easier for
you (and Debian).
Cheers
Dave
$ cat /etc/cron.d/php5
# /etc/cron.d/php5: crontab fragment for php5
# This purges session files older than X, where X is defined in seconds
# as the largest value of session.gc_maxlifetime from all your php.ini
# files, or 24 minutes if not defined. See /usr/lib/php5/maxlifetime
# Look for and purge old sessions every 30 minutes
09,39 * * * * root [ -x /usr/lib/php5/maxlifetime ] &&
[ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin
+$(/usr/lib/php5/maxlifetime) -print0 | xargs -r -0 rm
_______________________________________________
phpGroupWare-developers mailing list
http://lists.gnu.org/mailman/listinfo/phpgroupware-developers

[chris]

Post by Chris Weiss
it's always been my impression that php's garbage collection, not a
cron job, handles removing old session files. maybe what we have a
bug in php itself...

Garbage collection is disabled in debian, this allows strict permissions
on /var/lib/php5.
drwx-wx-wt 2 root root 4096 avr 18 10:09 .

That if I understand well, let any user create a file and only the one
that created the file remove it.
So it is not possible to parse the directory. Thats why the cron job is
there.
My guess is that we will need to enable the gc
in /etc/apache2/conf.d/phpgroupware

php_value session.gc_probability 1


C.Bac

Post by Chris Weiss
_______________________________________________
phpGroupWare-developers mailing list
http://lists.gnu.org/mailman/listinfo/phpgroupware-developers

[Olivier Berger]

Post by chris

Post by Chris Weiss
it's always been my impression that php's garbage collection, not a
cron job, handles removing old session files. maybe what we have a
bug in php itself...

Garbage collection is disabled in debian, this allows strict permissions
on /var/lib/php5.
drwx-wx-wt 2 root root 4096 avr 18 10:09 .
That if I understand well, let any user create a file and only the one
that created the file remove it.
So it is not possible to parse the directory. Thats why the cron job is
there.
My guess is that we will need to enable the gc
in /etc/apache2/conf.d/phpgroupware
php_value session.gc_probability 1

Hmmm... Chris, can you provide some ref docs on that garbage
collecting ?

I'm not sure you came to the same conclusion, reading your other post at
http://lists.alioth.debian.org/pipermail/pkg-php-maint/2008-May/004010.html :-/

Can you summarize your advice (and CC:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479905) ?

Best regards,

[Chris Weiss]

On Tue, May 27, 2008 at 11:08 AM, Olivier Berger

Post by Olivier Berger

Post by chris

Post by Chris Weiss
it's always been my impression that php's garbage collection, not a
cron job, handles removing old session files. maybe what we have a
bug in php itself...

Garbage collection is disabled in debian, this allows strict permissions
on /var/lib/php5.
drwx-wx-wt 2 root root 4096 avr 18 10:09 .
That if I understand well, let any user create a file and only the one
that created the file remove it.
So it is not possible to parse the directory. Thats why the cron job is
there.
My guess is that we will need to enable the gc
in /etc/apache2/conf.d/phpgroupware
php_value session.gc_probability 1

Hmmm... Chris, can you provide some ref docs on that garbage
collecting ?
I'm not sure you came to the same conclusion, reading your other post at
http://lists.alioth.debian.org/pipermail/pkg-php-maint/2008-May/004010.html :-/
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479905) ?

this is becoming less clear. the wwwroot user does all access to the
files, no matter what phpgw user is logged in. I don't see how file
permissions affect this.

What I know about the subject is simply from memory of talking to php
developers (the ones that write the php engine) in ##php on freenode,
though that was a while ago, about when php5 was released.

[Olivier Berger]

Post by Chris Weiss
On Tue, May 27, 2008 at 11:08 AM, Olivier Berger

Post by Olivier Berger
I'm not sure you came to the same conclusion, reading your other post at
http://lists.alioth.debian.org/pipermail/pkg-php-maint/2008-May/004010.html :-/
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479905) ?

this is becoming less clear. the wwwroot user does all access to the
files, no matter what phpgw user is logged in. I don't see how file
permissions affect this.

Unless there are both mod-php and CGIs running on the same machine, but
with different users, or other suexec mechanisms, I suppose.

Regards,