| Date | Commit message (Collapse) |
|---|
|
This release fixes a denial-of-service vector for deployments
exposed directly to untrusted clients.
The HTTP parser in Unicorn <= 0.97.0 would trip an assertion
(killing the associated worker process) on invalid
Content-Length headers instead of raising an exception. Since
Rainbows! and Zbatery supports multiple clients per worker
process, all clients connected to the worker process that hit
the assertion would be aborted.
Deployments behind nginx are _not_ affected by this bug, as
nginx will reject clients that send invalid Content-Length
headers.
The status of deployments behind other HTTP-aware proxies is
unknown. Deployments behind a non-HTTP-aware proxy (or no proxy
at all) are certainly affected by this DoS.
Users are strongly encouraged to upgrade as soon as possible,
there are no other changes besides this bug fix from Rainbows!
0.91.0 nor Unicorn 0.97.0
This bug affects all previously released versions of Rainbows!
and Zbatery.
|
|
We don't have "worker" processes in here.
|
|
Eric Wong (7):
use Unicorn.builder to parse config.ru switches
import selected parts of test suite from Rainbows!
gemspec: depend on newer Unicorn for Unicorn.builder
support "user" directive outside of after_fork hook
MRI 1.8 thread fix to avoid blocking accept()
disable more Unicorn methods
support Unicorn 0.96.0+ ready_pipe daemonization
|
|
ready_pipe allows the controlling process to detect
errors more reliably.
|
|
init_self_pipe! and trap_deferred are worthless and
possibly harmful to us
|
|
Rainbows! commit ee7fe220ccbc991e1e7cbe982caf48e3303274c7
Under MRI 1.8, listen sockets do not appear to have the
nonblocking I/O flag on by default, nor does it set the
nonblocking I/O flag when calling #accept (but it does
when using #accept_nonblock, of course).
Normally this is not a problem even when using green threads
since MRI will internally select(2) on the file descriptor
before attempting a blocking (and immediately successful)
accept(2).
However, when sharing a listen descriptor across multiple
processes, spurious wakeups are likely to occur, causing
multiple processes may be woken up when a single client
connects.
This causes a problem because accept(2)-ing on multiple
threads/processes for a single connection causes blocking accepts in
multiple processes, leading to stalled green threads.
This is not an issue under 1.9 where a blocking accept() call
unlocks the GVL to let other threads run.
|
|
This is new in Unicorn 0.97.0, and makes sense to us since we
don't fork. It won't work as nicely with log reopening in some
cases, but it's better than nothing
|
|
|
|
|
|
Less code to maintain this way.
|
|
Unicorn had a memory that didn't affect Unicorn, but only
Rainbows!, so we bumped the dependency on Rainbows!
which in turn bumped the dependency on Unicorn...
Also some minor documentation updates.
|
|
Rainbows! >= 0.90.2 depends on Unicorn >= 0.96.1,
which will work around a memory leak found in
previous versions of Unicorn::HttpParser.
|
|
working_directory and Worker#user got added over time, so
recommending Dir.chdir and Process::UID.change_privilege
is bad.
|
|
This gem release allows compatibility with newer versions of
Rainbows! This also fixes a bug when $stdout is not redirected
to a file.
|
|
|
|
|
|
$stdout may not have been a chown-able file descriptor,
so throw in a dummy object there that absorbs chown calls.
|
|
* make it clear we depend on Unicorn and Rainbows!
* point out Sunshowers
* add FAQ
|
|
We do not expect Rainbows! internals we depend on to change
significantly before Rainbows! 1.0.0.
|
|
|
|
|
|
Shells already expand '~' before the executables see it, and
relative paths inside symlinks can get set incorrectly to the
actual directory name, and not the (usually desired) symlink
name for things like Capistrano.
Since our paths are now unexpanded, we must now check the
"working_directory" directive and raise an error if the user
specifies the config file in a way that makes the config file
unreloadable.
|
|
|