Ticket #1484678 (new Bugs)
Method session_start with custom session handlers is not thread-safe.
| Reported by: | micha | Owned by: | |
|---|---|---|---|
| Priority: | 5 | Milestone: | 0.2-stable |
| Component: | Core functionality | Version: | 0.1-rc2 |
| Severity: | normal | Keywords: | login redirect session periodical |
| Cc: |
Description
There is a problem with the login, where after some logins and logouts, every new Login-Attempt kicked me back to the login screen. Without any mention of a problem in the logs.
The problem is, that the method session_start with the custom session handlers is not thread-safe. So it is possible that the logout and the periodical mail checking process occur at the same time.
The events occur in the following order:
- sess_read called by logout.
- sess_read called by periodical Mail-Check.
- sess_write (with $vars (temp|b:1)) called by logout.
- sess_write ($vars without temp) called by periodical mail check, overwrites sess_write from the step before.
Step 4 ("mail check") overwrites the Session-Parameters from Step 3 ("logout"). The concrete problem in that case is the temp-Parameter. Next login, session_start reads in the session parameter, where "temp" must be true, to start a new session. Otherwise when ("temp" == false), roundcube expects a valid session and tries to resume that session. (In index.php, $_SESSION\['temp'\] will be checked but fails.)
The only way a new login is possible, is to reset the cookies (restart IE and delete cookies in Firefox).
From my point of view, the php session methods (session_start, session_destroy, ...) that use the custom session handlers (sess_open, sess_close, sess_read, sess_write, ...) must be atomic. So when two session_start methods occur at the same time, they don't influence each other any more.
