-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
thread-safe mode with luasocket, microtime and central storage #6
Comments
@Tieske, I have created an script that runs 256 processes, each of them use method above to get a unique seed: uuid_test.lua: https://gist.github.com/develCuy/87a52426f7d2dc2b1948 This is how to run the test:
|
Obviously depending on the use case it could be wrapped to include such a check. But I do not think it should be part of this library. |
Instead of creating many files, why not creating a single one, and upon seeding, keep it open for several milliseconds, before closing it again. If the file cannot be created, sleep for a few milliseconds, and try again. |
anyway; remember that file based stuff can turn out to become blocking and stop a server process. |
"file based stuff can turn out to become blocking and stop a server process" true! This is how the session library from CGILua crashes the process if it receives a large number of requests - it makes some insecure file operations when creating a new session, so someone can trigger this and make a simple denial-of-service attack. |
The less it relies on file based operations the more reliable and secure it will be |
@felipedaragon, 256 processes in parallel is an extreme use case. There are about 1 to 8 threads (2 per core) in a dev server and 8 to 64 in a production server. A good setup runs one worker per thread, so the most extreme case is actually 64 processes in parallel. Also, they only compete for a unique seed when they start, as the uuid library should be loaded once per worker. The amount of file operations is pretty acceptable IMHO, no DoS risk at all. Now, if somebody is running a CGI server, so that uuid module is loaded once per http request, such setup is risky not because of file operations, but because of CGI, we should document that CGI is not recommended for servers with more than 4 threads, so that there are only 4 processes competing for a seed. |
@develCuy you're probably right. I just wanted the new session library to be the most solid and resilient we can get. PS: you put an extra D to DoS. With the CGILua thing I was just referring to the classic, non-distributed form :) |
should be fixed by #17 , it uses a table id (and hence ASLR), as well as provides a way to pass in any additional user data (eg. mac address, etc) for seeding. |
Hello, I'm following from this Kong/kong#695 and sailorproject/sailor#58
I want to propose the following solution for the seeding issue:
This way we get a different seed for each thread. Production servers can run tmpfs (in-memory filesystem) to optimize speeds (no need to relay on database storage).
I know this has limitations, but who in the world is running more than 256 threads on a single microsecond?
The text was updated successfully, but these errors were encountered: