Data Corruption vulnerability on TinyDB version 4.7.1 about tinydb

[MrPigss]

Using multi- processing/threading is not natively supported by TinyDB. It's not specifically mentioned in the docs but it does list it as a reason not to use TinyDB (see here).

It is perfectly possible to use TinyDB with multi- processing/threading but you'll need to put locks in the appropriate places.

In other words this is not a bug, but maybe it should be mentioned in the docs more clearly.

Edit:
I see you use app.run(), this shouldn't be using more than one thread or process (unless the threaded or processes params are set). In short, this should work. Did you use something like gunicorn, uvicorn, ... when running this test? If not then this might indeed be a bug.

[deadoverflow]

I just ran app.run() without using gunicorn or anything like that, i just straight up ran python app.py.

In theory, yes this was not mentioned in the docs which means developers are going to use tinydb in their applications and when deploying to for example namecheaps hosting service, it takes passenger_wsgi.py file which just imports the application from its respective server file and preforms app.run(). So it only starts one process which is what i initially tested.

app.run() will in fact start only one process so yeah i think this could be a bug but not entirely sure about it either

If you want me to upload folder where are all the files that i used for testing i will gladly do so.

[deadoverflow]

Well, when two users send each a HTTP request to the flask server, the server would handle them asynchronously, meaning this opens up for a multi threading. One thread (or request) is trying to preform a write to the db while second thread just started and is behind first thread for 0.02 seconds for example. Than this race condition somehow corrupts the last byte of the db.

This could not be a bug but definitely shall be mentioned in the documentation of the tinydb so that developers can effectively take action to avoid this behavior which causes disruption of service in the end. Especially developers who are trying to implement tinydb on their web applications will find this information crucial as without it, their website is prone to easy DOS with no questions asked!

[deadoverflow]

i see that you have updated the docs for tinydb v4.8.0 i think. The "Why not use TinyDB" section implies that if you want to use tinydb in HTTP server environment, you should probably look for better solutions. I think this sums it up!

[msiemens]

i see that you have updated the docs for tinydb v4.8.0 i think.

I just looked this up and this sentence has been there since at least v3.0.0 (back in 2015!) 🙂

The point about Flask is correct though. Back when I developed TinyDB, Flask did NOT have multithreading. So it never crossed my mind that using TinyDB with Flask could cause any problems. But since v1.0 in 2018, Flask decided to turn on multithreading by default. I've now updated the documentation to explicitly mention this fact.