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/02 01:49]
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 51: Line 51:
                              ↓                              ↓
        ​         Close (Session data unchanged)        ​         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.
  
  
Line 60: 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 92: 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 137: 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 unsafe_lock=On:​ New behavior with unsafe_lock=On:​
Line 261: 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 279: 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 287: 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 293: 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 309: 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 317: 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 323: 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.1391305751.txt.gz · Last modified: 2017/09/22 13:28 (external edit)