rfc:session-lock-ini

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
rfc:session-lock-ini [2014/02/01 23:40]
yohgaki 		rfc:session-lock-ini [2017/09/22 13:28] (current)
Line 1: Line 1:
  
-====== PHP RFC: Introduce session options - read_only, unsafe_lock, lazy_write and lazy_destroy ======+====== PHP RFC: Introduce session_start() options - read_only, unsafe_lock, lazy_write and lazy_destroy ======
   * Version: 1.6   * Version: 1.6
   * Date: 2014-02-02    * Date: 2014-02-02 
   * Author: Yasuo Ohgaki, yohgaki@ohgaki.net   * Author: Yasuo Ohgaki, yohgaki@ohgaki.net
-  * Status: Under Discussion+  * Status: Passed Proposal 1. 2 and 3 declined.
   * First Published at: http://wiki.php.net/rfc/session-lock-ini   * First Published at: http://wiki.php.net/rfc/session-lock-ini
  
Line 25: Line 25:
 **proposal 3: unsafe_lock** **proposal 3: unsafe_lock**
  
-Add unsafe_lock option for concurrent script execution. Currently, script execution is serialized when session is used. unsafe_lock=on allows script access session data concurrently. When lazy_write=on, only updated data is saved. Applications can maintain consistency by saving updated session data only.+Add unsafe_lock option for maximum concurrent script execution. Currently, script execution is serialized when session is used. unsafe_lock=on allows script access session data concurrently. When lazy_write=on, only updated data is saved. Applications can maintain consistency by saving updated session data only. 
 + 
 +Suppose there is concurrent access from a same client Connection A and B with unsafe_lock=On , lazy_write=On. 
 + 
 +  Connection A          Connection B 
 +      ↓                     ↓ 
 +  Open Session          Open Session　 
 +      ↓                     ↓ 
 +  Login                 Does not care auth status. Just read session. 
 +      ↓                     ↓ 
 +  Close　　　　　　　　　Close (Session data unchanged) 
 + 
 +Auth info set by Connection A never deleted by Connection B. Read only session achieves similar execution, but it has to wait lock. Therefore, previous access became 
 + 
 +  Connection A          Connection B 
 +      ↓                     ↓ 
 +  Open Session          Wait lock　 
 +      ↓                     ↓ 
 +  Login                      ↓ 
 +      ↓                     ↓ 
 +  Close　　　　　　　　　     ↓ 
 +                        Open Session　 
 +                             ↓ 
 +                        Does not care auth status. Just read session. 
 +                             ↓ 
 +       　　　　　　　　　Close (Session data unchanged) 
 + 
 +**Usage Tip for unsafe_lock=On: ** Update $_SESSION only when update is strictly needed. For example, change $_SESSION only when authentication/authorization information has changed. Alternatively, user may start all session with read_only=TRUE and reopen session with read/write only when authentication/authorization information has to be changed. 
  
 **proposal 4: lazy_destroy** **proposal 4: lazy_destroy**
Line 34: Line 62:
   * Script B accessed to server with old session ID   * Script B accessed to server with old session ID
  
-Current session module(session_destroy()/session_regenerate_id()) simply deletes session data with $delete_old_session=true. When $delete_old_session=false(default), session_regenerate_id() simply creates new session ID and leave old session ID/data.+Current session module(session_destroy()/session_regenerate_id()) simply deletes session data with $delete_old_session=true. When $delete_old_session=false(default), session_regenerate_id() simply creates new session ID and leaves old session ID/data.
  
 Even when old session ID is destroyed, script B can access server with old session ID. Without session.strict_mode=On, session module may reinitialize session data with old ID which may be known to attackers. Even when old session ID is destroyed, script B can access server with old session ID. Without session.strict_mode=On, session module may reinitialize session data with old ID which may be known to attackers.
Line 66: Line 94:
  
  
-===== Proposal 2 - lazy_wirte =====+===== Proposal 2 - lazy_write =====
  
 Introduce lazy_write option to session_start() that enable/disable lazy session data writing. Introduce lazy_write option to session_start() that enable/disable lazy session data writing.
Line 89: Line 117:
 For files save handler, PS_UPDATE_FUNC() is not needed as it can update mtime at PS_OPEN_FUNC(). Files save handler's PS_UPDATE_FUNC() will be empty function that simply return true. For files save handler, PS_UPDATE_FUNC() is not needed as it can update mtime at PS_OPEN_FUNC(). Files save handler's PS_UPDATE_FUNC() will be empty function that simply return true.
  
-For memcache/memcached/redis/etc save handlers, PS_UPDATE_FUNC() is not needed since read access(PS_READ_FUNC()) updates last access time stamp. PS_UPDATE_FUNC() may return true simply.+For memcache/memcached/redis/etc save handlers, PS_UPDATE_FUNC() is not needed since read access(PS_READ_FUNC()) updates last access time stamp. PS_UPDATE_FUNC() may return success simply.
  
-Other save handlers should support PS_UPDATE_FUNC() API to update last access time. Otherwise, garbage correction may remove active sessions. Alternatively, save handler may update last access time when PS_OPEN()/PS_READ_FUNC() is called, then PS_UPDATE_FUNC() may return true simply.+Other save handlers should support PS_UPDATE_FUNC() API to update last access time. Otherwise, garbage correction may remove active sessions. Alternatively, save handler may update last access time when PS_OPEN()/PS_READ_FUNC() is called, then PS_UPDATE_FUNC() may return success simply.
  
 ===== Proposal 3 unsafe_lock option===== ===== Proposal 3 unsafe_lock option=====
Line 97: Line 125:
 Session module locks session data while executing script by default. This make sure session data integrity by serializing script execution. i.e. Only a script may have access to session data at the same time. Session module locks session data while executing script by default. This make sure session data integrity by serializing script execution. i.e. Only a script may have access to session data at the same time.
  
-Current behavior ensure session data integrity, but it serializes script execution and slows down application performance.+Current behavior ensures session data integrity, but it serializes script execution and slows down application performance.
  
 For user defined save handlers, locking is up to users. Memcached session save handler has lock ini option for better performance by sacrificing integrity a little. Second proposal mitigates broken integrity by unlocked session data access.  For user defined save handlers, locking is up to users. Memcached session save handler has lock ini option for better performance by sacrificing integrity a little. Second proposal mitigates broken integrity by unlocked session data access. 
  
-Introduce lock option to session_start() that enable/disable session data lock.+Introduce unsafe_lock option to session_start() that enable/disable session data lock.
  
   unsafe_lock - FALSE by default.   unsafe_lock - FALSE by default.
Line 111: Line 139:
 Current behavior: Current behavior:
  
-  Open session data   -----------------+  Open session data    
 +   ↓                          
 +  Read session data   ----------------- 
    ↓                         ↑    ↓                         ↑
-  Read session data           ｜ +  （Script execution）      Locked  
-   ↓ +   ↓                         ↓ 
-  （Script execution）      Locked +  Write session data  ------------------  
-   ↓ +   ↓　                        
-  Write session data          ｜ +  Close session data  
-   ↓　                       ↓ +
-  Close session data  ------------------+
  
-New behavior with lock=Off:+New behavior with unsafe_lock=On:
  
      
Line 235: Line 263:
   - lazy_write=TRUE could improved 2 times or better performance by removing write() calls.   - lazy_write=TRUE could improved 2 times or better performance by removing write() calls.
   - lazy_write=TRUE provides better data consistency since only modified session data is written when session.lock=FALSE,    - lazy_write=TRUE provides better data consistency since only modified session data is written when session.lock=FALSE, 
 +
  
 **Cons.** **Cons.**
   - Session behavior is changed. When lazy_write=Off, "last session written" wins. When lazy_write=TRUE, "last session modified" wins.    - Session behavior is changed. When lazy_write=Off, "last session written" wins. When lazy_write=TRUE, "last session modified" wins. 
-  - Programmers are responsible for ensuring data consistency when lock=FALSE.+  - Programmers are responsible for ensuring data consistency when unsafe_lock=TRUE.
  
 **3) unsafe_lock** that control session data locking. **3) unsafe_lock** that control session data locking.
  
 **Pros** **Pros**
-  - Simpler and faster than session_lock() API. e.g. This API requires additional access to data storage which make data handling more complex and slower.+  - Maximum concurrency (= better performance) 
 +  - Programmer does not have to selectively start session. (i.e. read only or not) Simplify code.
   - Allow concurrency without explicit calls of session_commit(), session_write_close(), session_abort().   - Allow concurrency without explicit calls of session_commit(), session_write_close(), session_abort().
 +  - Simpler and faster than session_lock() API. e.g. This API requires additional access to data storage which make data handling more complex and slower.
  
 **Cons** **Cons**
   - Misuse of this feature could be a cause of bugs.   - Misuse of this feature could be a cause of bugs.
 +  - Open all session with read_only=TRUE and reopen session for writing as it is needed, would be safer for average users. (We may better to promote this usage pattern)
  
 **4) lazy_destroy** that allows delayed session data deletion for concurrent accesses and reliable session_regenerate_id() operation. **4) lazy_destroy** that allows delayed session data deletion for concurrent accesses and reliable session_regenerate_id() operation.
Line 253: Line 285:
 **Pros** **Pros**
   - session_regenerate_id() becomes more reliable for reasons described below.   - session_regenerate_id() becomes more reliable for reasons described below.
-  - Mitigate race condition that creates unneeded sessions. NOTE: Unneeded session created by race condition could be known session to attacker. Unneeded session increase system load. +  - Ensures proper application behavior even when network connection is unreliable. This is important for mobile applications especially. 
-  - Ensure proper application behavior even when network connection is unreliable. This is important for mobile applications especially.+  - Mitigates race condition that creates unneeded sessions. NOTE: Unneeded session created by race condition could be known session to attacker. Unneeded session increase system load.
  
 **Cons** **Cons**
Line 261: Line 293:
  
  
-Please note that **lazy_destroy is mandatory for reliable session_regenerate_id()/session_destroy()** operation even if this RFC is proposing to disable it by default. Please refer to referenced discussion for details. +Please note that **lazy_destroy is mandatory for reliable session_regenerate_id()/session_destroy()** operation. Please refer to referenced discussion for details. 
  
 Please propose alternative solution if you vote no to this proposal. This is security related change so there must be alternative solution. session_regenerate_id() cannot delete old session without delayed deletion or alternative solution if there is. Please propose alternative solution if you vote no to this proposal. This is security related change so there must be alternative solution. session_regenerate_id() cannot delete old session without delayed deletion or alternative solution if there is.
Line 267: Line 299:
  
 ===== Benchmark ===== ===== Benchmark =====
 +
 +Note: read_only=on will yield better result than this.
  
 == lazy_write: on, unsafe_lock: on == == lazy_write: on, unsafe_lock: on ==
Line 283: Line 317:
 Please vote feature by feature. Please vote feature by feature.
  
-The voting period is 2014/02/03 until 2014/02/10.+The voting period is 2014/02/12 until 2014/02/19.
  
 1,2) Introduce read_only, lazy_write to session_start() option.  1,2) Introduce read_only, lazy_write to session_start() option. 
Line 291: Line 325:
 </doodle> </doodle>
  
-3) Introduce unsafe_lock option. +3) Introduce unsafe_lock option to session_start() option. 
 <doodle title="Unsafe lock option" auth="user" voteType="single" closed="true"> <doodle title="Unsafe lock option" auth="user" voteType="single" closed="true">
    * Yes    * Yes
Line 297: Line 331:
 </doodle> </doodle>
  
-4) Introduce lazy_destroy option. +4) Introduce lazy_destroy option to session_start() option. 
 <doodle title="Lazy destroy option" auth="user" voteType="single" closed="true"> <doodle title="Lazy destroy option" auth="user" voteType="single" closed="true">
    * Yes    * Yes
rfc/session-lock-ini.1391298020.txt.gz · Last modified: 2017/09/22 13:28 (external edit)

Page Tools