Edit report at https://bugs.php.net/bug.php?id=80291&edit=1
ID: 80291
Comment by: rtrtrtrtrt at dfdfdfdf dot dfd
Reported by: jozyah-etienne at eerees dot com
Summary: Data corruption and data loss in default session
handler (All PHP versions)
Status: Open
Type: Bug
Package: Session related
PHP Version: Next Major Version
Block user comment: N
Private report: N
New Comment:
> And if a very very negligible overhead is so problematic
> to you that you want to risk your users' data
yes because "in case of failure (power outage, disk failure, crash, connection loss to a
networked storage" don't happen in the real world
* each server has two power supplies
* each power supply is on a different UPS
* disk failures don't matter on redundant arrays
* my servers don't crash
* my storags don't lose connections - redundancy is the keyword
again: your issue don't exist in ten real world and you should fix the root cause
Previous Comments:
------------------------------------------------------------------------
[2020-10-29 02:50:33] jozyah-etienne at eerees dot com
If nobody here wants to have this very very negligible overhead in his/her websites, that's
fine. But docs should clearly mention this problem and also introduce a solid way to those who care
for their users data and experience and users' trust on site owners and programmers trust on
PHP as a tool.
There are 3 ways to solve the issue:
1. Fix the problem as a bug for all PHP websites out there.
2. Introduce a new function such as session_write_close_atomic() so programmers can decide.
3. Introduce a new boolean config in php.ini such as session.atomic_write so sysadmins can decide.
And please don't say that data is not important, they are, at least to those of us who care.
------------------------------------------------------------------------
[2020-10-29 02:44:43] jozyah-etienne at eerees dot com
> nobody cares about session files, they are in tmpfs here for 20 years
> session data aren't unless you have way bigger problems and then they are not important
Who says so? Are there any conventions out there that programmers agreed on? Are there any
notifications in docs saying so? NO!
> the worst case every few decades is that one needs to login again which is the same for every
> ordinary reboot in that setup
And he/she will lose all his/her session data because some unknown guy on internet said that a very
very negligible overhead worth much more than his/her session data!
I don't know about the default handler handler, but what if he/she can not logout? what if he
needs to clear the cookie from the browser by him/herself? What if there are hundreds of users that
lost their data and they all have problem logging out? How many hours the programmers need to
scratch their head to find the reason?
> it don't happen except for cases where you have *much larger* problems - period
And if a very very negligible overhead is so problematic to you that you want to risk your
users' data and their experience on trust on you, you have *much larger* problems too - period
------------------------------------------------------------------------
[2020-10-28 20:46:30] rtrtrtrtrt at dfdfdfdf dot dfd
> It took less than 1 second to rename a file for 100,000 times
in 1 second i spit out 20000-50000 dynamic pages
nobody cares about session files, they are in tmpfs here for 20 years
the worst case every few decades is that one needs to login again which is the same for every
ordinary reboot in that setup
> I'm saying, most programmers are using standard session
> handler and they are not aware that data loss and data
> corruption can happen
it don't happen except for cases where you have *much larger* problems - period
> It's all about how important your data is
session data aren't unless you have way bigger problems and then they are not important
------------------------------------------------------------------------
[2020-10-28 17:14:04] jozyah-etienne at eerees dot com
Better summary :D
------------------------------------------------------------------------
[2020-10-28 17:00:53] jozyah-etienne at eerees dot com
> session files are *temporary* data and if you really insist in atomic writes please use a
> sql-based session handler but don't make my setups slower for cases which never happen at all
They are *temporary*, not *cached*.
Temporary data are important, cached data are not.
You need those temporary data to serve your user, otherwise bad things can happen, from a simple
user logout to massive data losses.
Also, even cached data are important if a data loss during write could break your production and you
are not aware of it.
> looks like you never where targetr auf a serious DDOS!
> in that case you are graceful for every overhead you can save
I just executed the following code:
#$i = 0;
#$start = microtime(true);
#do
#{
# rename('./temp.'.$i, './temp.'.($i+1));
#} while($i++ < 100000);
#$total = microtime(true) - $start;
#var_dump($total);
It took less than 1 second to rename a file for 100,000 times in my 7 years old, 2 core, super slow
laptop. That's a 0.00001 seconds overhead per request. You know why? because the needed inodes
(or whatever needed in the process) are already found and cached by operating system & PHP
during write operation.
If you really need to optimize your site for 0.00001 seconds, you are long in a wrong way, because
definitely PHP is not the right tool for your use case. Also in that case, your hardware
infrastructure is also not meeting your needs and spending a couple of $bucks to upgrading your
hardware is much better than putting yourself in danger of data loss.
> how often do you have poweroutage without UPS, dying disks without RAID and crashes at all on
> production servers?
>
> the one case every few decades where *probably* a ssession file my get corrupt don't
> matter that much
You are wrong, it's not about how good your infrastructure is, it's about how reliable
your tool is and how much you can trust it.
It's all about how important your data is and how often you (as a programmer) know that your
data is really important and also you know that the tool you are using is not reliable so you know
that you shouldn't trust the tool and you know that you need to handle the scenario all by
yourself so in case of data loss, you don't need to bang your head against the wall to find the
source of problem.
It's all about trusting the tool you are using that it can do it's job, and do it well,
and do it in a reliable fashion.
And to answer your specific question, yes, data gets lost all the time, even in professional-grade
servers in profession-grade data centers, that's why databases are ACID and we use transactions
to avoid such marginal, once in a life time disaster cases, otherwise they would be way faster than
they are.
And to answer your question with other questions:
* How often do you have SQL injection or code injection? So why bother and use precious CPU clocks
and RAM and Disk space to convert passwords to hashes using slow algorithms?
* How often do you hit with a timing attack on a non-real-time, threaded server and operating
system? So why bother yourself and use hash_equals() instead of "==="?
* How often do you hit with a serious DDoS attack that a 0.00001 seconds long operation becomes so
important to you that you prefer to ask for troubles instead of doing jobs in secure, reliable way?
I'm saying, most programmers are using standard session handler and they are not aware that
data loss and data corruption can happen. This is an important bug that needs to be fixed. If a
0.00001 seconds operation is so important in DDoS attacks, at least a option like
session_write_close_atomic() should be added so the programmer can chooses between reliability and
0.00001 seconds optimization.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=80291
--
Edit this bug report at https://bugs.php.net/bug.php?id=80291&edit=1