[php-maint] Bug#621360: Bug#621360: /etc/cron.d/php5 wreaks havoc on session-based PHP apps

[Ondřej Surý]

severity 621360 wishlist
tags 621360 +wontfix
thank you

Hi David,

you seem to misunderstand the concept of the cron job. The cron job
itself serves no purpose, but it has to be there since the
/var/lib/php5 should not be readable by www-data (or any other user)
for security reasons - you certainly don't want any script running
under www-data user to be able to read other webs sessions.

As for SugarCRM you're free to re-enable the GC, disable the cron job
or set the session directory to some other and do whatever
modification (like just setting the timeout to 6 hours, etc) you need.

Also if you feel that the description in php5-common README.Debian is
not sufficient, we are certainly open to any suggestions how to
improve the text.

O.

On Wed, Apr 6, 2011 at 22:49, David Norris <dnorris at dkiservices.com> wrote:
> Package: php5
> Version: 5.3.2-1ubuntu4.2
> Severity: important
>
> The cron job assumes that all PHP scripts use the global max lifetime value.  I have never, once, ever seen a PHP script that recommends using the default settings as a good idea.  For example, I am using SugarCRM.  The cron job is blindly vaporizing session data every 30 minutes despite the fact that SugarCRM changes this value locally.  The effect this has is devastating to the operation of SugarCRM.  Ajax calls into the application often get redirected to a login dialog due the the session disappearing at inappropriate times.  When this occurs it causes data loss in the application.
>
> Also, it seems inappropriate to me to change the global php.ini setting at all for any reason.  Those are very reasonable defaults.  However, within Apache you may want to locally modify the max lifetime for a particular vhost to a value which is unreasonable to other vhosts.  Such as SugarCRM where we want sessions to last an entire 8 hour shift.
>
> I question whether this cron job serves any purpose at this point.  It seems to be working around a bug in the Debian PHP 4.0 package from2004.  I have been testing today and PHP 5.3 appears to be garbage collecting sessions appropriately.  The permissions seem to suggest there should be no problems, as well.
>
> The original Debian Bugs which prompted the addition of the cron job and move of session data to /var/lib/php[4|5] are #256831 and #257111
>
>
> Sorry, the system info is probably a bit ugly as this is an Ubuntu system but the problem originates from Debian so I chose to submit to debian bts.
>
> -- System Information:
> Debian Release: squeeze/sid
>  APT prefers lucid-updates
>  APT policy: (500, 'lucid-updates'), (500, 'lucid-security'), (500, 'lucid')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 2.6.32-21-server (SMP w/2 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
>
> Versions of packages php5 depends on:
> ii  libapache2-mod-php5     5.3.2-1ubuntu4.2 server-side, HTML-embedded scripti
> ii  php5-common             5.3.2-1ubuntu4.2 Common files for packages built fr
>
> php5 recommends no packages.
>
> php5 suggests no packages.
>
> -- no debconf information
>
>
>
> _______________________________________________
> pkg-php-maint mailing list
> pkg-php-maint at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/pkg-php-maint
>



-- 
Ondřej Surý <ondrej at sury.org>
http://blog.rfc1925.org/