Php cron job fails when there are a lot of session files in /var/lib/php5
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
php5 (Ubuntu) |
Confirmed
|
Wishlist
|
Unassigned |
Bug Description
Binary package hint: php5
root@eris:
Description: Ubuntu 8.04.3 LTS
Release: 8.04
root@eris:
php5:
Installed: 5.2.4-2ubuntu5.6
Candidate: 5.2.4-2ubuntu5.7
Version table:
5.
500 http://
500 http://
*** 5.2.4-2ubuntu5.6 0
100 /var/lib/
5.2.4-2ubuntu5 0
500 http://
root@eris:
-- Description:
The cron job /etc/cron.d/php5 is meant to clear out /var/lib/php5 of old session files, which is fine generally... But:
The cron job uses xargs with the -0 option - This is the effect on a cleanish and newly purged (30 seconds ago) directory:
root@eris:
.
./sess_
./sess_
./sess_
./sess_
./sess_
./sess_
./sess_
./sess_
./sess_
./sess_
./sess_
root@eris:
However - This is a very full directory such as the one that completely filled my disk yesterday:
root@eris:
xargs: argument line too long
root@eris:
This results in the disk with /var on it filling and the system becoming completely unusable - Which is why I ticked the security vulnerability since effectively, this is a DOS, you may feel free to disagree.
So far my fix is one of:
1. Run the cron job more often so it doesn't fill the thing so much it can't be deleted (poor hack)
2. Remove the -0 option to xargs in /etc/cron.d/php5 - Since -0 is new to me and seems to have little documentation I am not sure what this will break.
3. Change the lifetime of the session files in /usr/lib/
Only 2 is a good solution but I am still wondering why they used -0 and if there is a valid reason for it.
** This could of course be a bug in xargs but it manifests in php5 and since I don't have a clue what -0 is meant to do, I am not going there...
Michael.
visibility: | private → public |
Changed in php5 (Ubuntu): | |
importance: | Undecided → Wishlist |
status: | New → Confirmed |
Thanks for taking the time to report this bug and helping to make Ubuntu better. We appreciate the difficulties you are facing, but this appears to be a "regular" (non-security) bug. I have unmarked it as a security issue since this bug does not show evidence of allowing attackers to cross privilege boundaries nor directly cause loss of data/privacy. Please feel free to report any other bugs you may find.