Skip Menu |

This queue is for tickets about the Apache-Session CPAN distribution.

Report information
The Basics
Id: 6936
Status: resolved
Priority: 0/
Queue: Apache-Session

Owner: CHORNY [...]
Requestors: fiji [...]

Bug Information
Severity: Important
Broken in: 1.6
Fixed in: 1.82_03

Subject: Apache::Session::Lock::File is not checking the return value of the flock calls
Download (untitled) / with headers
text/plain 390b
It is possible for a flock failure to cause flock to return without having acquired the lock. In this circumstance the code is not checking the return value of flock so it allows the protected region to run. This could lead to corruption of the protected Session file. For instance if EDEADLK is returned then process A and process B can both proceed although one should have died. -ben
Download (untitled) / with headers
text/plain 1.1k
To further comment, the default behavior of the module is frequently wrong. If there are two simultaneous requests that use the same session then: 1. Process A acquires a read lock 2. Process B acquires a read lock 3. A & B both write to the session 4. Process A unties the session, triggering it to acquire a write lock which blocks on B's read lock 5. Process B unties its session object, triggering it to acquire a write lock... and voila... deadlock The really nasty thing is that since the code is not reading the return value of flock, the deadlock is ignorred and both A and B can write to the file. This is pretty nasty and what I have done is segregate the requests by read and write access. Images, include files, and other support stuff that don't update the session get a "read only" lock. All other requests set the Transaction option so they get a write lock right off the bat. This solves the deadlock problem, but you still need to handle the other possible errors from flock. I have also changed things so that if we got a read-only lock we clear the modified bit before we untie (but not new or deleted since a session could be created from an access to a read-only page).
This ticket should be resolved. It was fixed in 1.82_03.

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to