6.0.0-alpha12
6/12/25

[#7712] Memcache Session handler, shouldn't unlock if no data in memcache
Summary Memcache Session handler, shouldn't unlock if no data in memcache
Queue Horde Framework Packages
Queue Version HEAD
Type Bug
State No Feedback
Priority 1. Low
Owners slusarz (at) horde (dot) org
Requester urkle (at) outoforder (dot) cc
Created 11/20/2008 (6048 days ago)
Due
Updated 12/14/2008 (6024 days ago)
Assigned 12/02/2008 (6036 days ago)
Resolved 12/14/2008 (6024 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch No

History
12/14/2008 03:58:11 PM Chuck Hagenbuch State ⇒ No Feedback
 
12/02/2008 06:30:30 PM Michael Slusarz Comment #2
State ⇒ Feedback
Reply to this comment

[Show Quoted Text - 17 lines]
Not understanding your concern clearly.  Is it a duplicate of this:

http://marc.info/?l=horde&m=122660520206201&w=2


11/20/2008 04:56:04 PM Chuck Hagenbuch State ⇒ Assigned
Assigned to Michael Slusarz
 
11/20/2008 04:54:43 PM urkle (at) outoforder (dot) cc Comment #1
Priority ⇒ 1. Low
Type ⇒ Bug
Summary ⇒ Memcache Session handler, shouldn't unlock if no data in memcache
Queue ⇒ Horde Framework Packages
Milestone ⇒
Patch ⇒ No
State ⇒ Unconfirmed
Reply to this comment
From looking through the current memcache session handler in CVS HEAD 
(and the FW 3 Branch), it seems that there is a locking issue that can 
occur on new sessions.



In the code you

1) create a lock

2) try and read the data from memcache. (in case of a new session this 
will be nothing)

3) if there is no data then you release the lock

.... Later on page close

1) write the data (creating a new session)

2) release lock if set.



Now, the issue is if two requests happen to occur around the same time 
when there is no session data (ie.. expired) then there is a high 
probability that they will overwrite each other.



Example

Req 1> New Request

Req 1> Fetch Session (no data, expired, release lock)

Req 2> New Request

Req 2> Fetch Session (No data, expired, release lock)

Req 2> Processing

Req 2> Store Session

Req 2> End Request

Req 1> Store Session

Req 1> End Request



Because there is no lock, Req 1 overwrites Req 2s data (and Req 2 is 
allowed to actually run even though it should have waited for Req 1).



The worse case is this, (ie login scenario)

R 1> New Request

R 1> Fetch Session (no data, expired, release lock)

R 1> Login attempt

R 2> Nww Request

R 2> Fetch Session (no data, expired, release lock)

R 1> Process Login

R 2> Do something else

R 1> Store Session

R 1> End Request

R 2> Store Session (Overwriting Requests 1's login session)

R 2> End Request



This results in the users session being overwritten by another request 
that user pushed through and thus, they are not logged in.



The solution would be to *NOT* release the lock if there is no 
session, because we ARE going to be writing at the end of the request.

Saved Queries