I liked the "drop privileges in Python for Tornado apps" article more. But even then, you would want to chroot/jail the user for more control over permissions.
I'm glad you enjoyed the article, or at least one of them, haha.
You're right, though, there are other options and considerations to be taken when considering the security of a web (or any) app. This is by no means a complete article on web app security and I hope nobody mistakes it as such
I think chroot/jailing is covered in quite a few other places, but it was difficult to find out how to go from running Tornado apps in development to running them in production. My aim is for my blog post(s) help make finding this information a little easier for others.
From what I understand, Tornado already starts multiple instances by default; the exact number of which is determined by the number of cores available. Is this still not adequate?
Please let me know because I would love to update my article(s) to be as accurate and as helpful as possible.
If request handlers block (by calling MySQL among other things), then one instance of Tornado per core may not be sufficient to take advantage of a machine's resources.
Tornado includes optional code to fork more than one instance where the number of instances defaults to the number of cores. Tornado's forking code has issues:
- There's no code to restart dead child processes.
- It's not possible to do a rolling upgrade because all instances of the server must be restarted at the same time.
I'd stay away from the forking code in Tornado. I suspect that it's not used by FriendFeed because the forking code was added well after the initial release of Tornado.
Not having to run software written by the creator of Qmail.
Kidding!
The first advantage I see is relying on one less externally-maintained service in your software stack. Other than that, I don't have technically sound reason for using one over the other.
12 comments
[ 3.7 ms ] story [ 43.7 ms ] threadYou're right, though, there are other options and considerations to be taken when considering the security of a web (or any) app. This is by no means a complete article on web app security and I hope nobody mistakes it as such
I think chroot/jailing is covered in quite a few other places, but it was difficult to find out how to go from running Tornado apps in development to running them in production. My aim is for my blog post(s) help make finding this information a little easier for others.
Thanks for the feedback!
Upstart does not help with the multiple instance problem. Upstart adds the problem of running code with elevated privilege.
I think it might be simpler to write a script to start/stop/restart daemon Tornado instances running in an unprivileged account.
From what I understand, Tornado already starts multiple instances by default; the exact number of which is determined by the number of cores available. Is this still not adequate?
Please let me know because I would love to update my article(s) to be as accurate and as helpful as possible.
Thanks!
Tornado includes optional code to fork more than one instance where the number of instances defaults to the number of cores. Tornado's forking code has issues:
- There's no code to restart dead child processes.
- It's not possible to do a rolling upgrade because all instances of the server must be restarted at the same time.
I'd stay away from the forking code in Tornado. I suspect that it's not used by FriendFeed because the forking code was added well after the initial release of Tornado.
Kidding!
The first advantage I see is relying on one less externally-maintained service in your software stack. Other than that, I don't have technically sound reason for using one over the other.
its more or less daemontools.. updated!