Comment from Matthew:
This fixes a potential issue where the Prosody process gets blocked on sockets
waiting for them to close. Unlike non-TLS sockets, closing a TLS socket sends
layer 7 data, and this can cause problems for sockets which are in the process
of being cleaned up.
This depends on LuaSec changes which are not yet upstream.
From Martijn's original email:
So first my analysis of luasec. in ssl.c the socket is put into blocking
mode right before calling SSL_shutdown() inside meth_destroy(). My best
guess to why this is is because meth_destroy is linked to the __close
and __gc methods, which can't exactly be called multiple times and
luasec does want to make sure that a tls session is shutdown as clean
as possible.
I can't say I disagree with this reasoning and don't want to change this
behaviour. My solution to this without changing the current behaviour is
to introduce a shutdown() method. I am aware that this overlaps in a
conflicting way with tcp's shutdown method, but it stays close to the
OpenSSL name. This method calls SSL_shutdown() in the current
(non)blocking mode of the underlying socket and returns a boolean
whether or not the shutdown is completed (matching SSL_shutdown()'s 0
or 1 return values), and returns the familiar ssl_ioerror() strings on
error with a false for completion. This error can then be used to
determine if we have wantread/wantwrite to finalize things. Once
meth_shutdown() has been called once a shutdown flag will be set, which
indicates to meth_destroy() that the SSL_shutdown() has been handled
by the application and it shouldn't be needed to set the socket to
blocking mode. I've left the SSL_shutdown() call in the
LSEC_STATE_CONNECTED to prevent TOCTOU if the application reaches a
timeout for the shutdown code, which might allow SSL_shutdown() to
clean up anyway at the last possible moment.
Another thing I've changed to luasec is the call to socket_setblocking()
right before calling close(2) in socket_destroy() in usocket.c.
According to the latest POSIX[0]:
Note that the requirement for close() on a socket to block for up to
the current linger interval is not conditional on the O_NONBLOCK
setting.
Which I read to mean that removing O_NONBLOCK on the socket before close
doesn't impact the behaviour and only causes noise in system call
tracers. I didn't touch the windows bits of this, since I don't do
windows.
For the prosody side of things I've made the TLS shutdown bits resemble
interface:onwritable(), and put it under a combined guard of self._tls
and self.conn.shutdown. The self._tls bit is there to prevent getting
stuck on this condition, and self.conn.shutdown is there to prevent the
code being called by instances where the patched luasec isn't deployed.
The destroy() method can be called from various places and is read by
me as the "we give up" error path. To accommodate for these unexpected
entrypoints I've added a single call to self.conn:shutdown() to prevent
the socket being put into blocking mode. I have no expectations that
there is any other use here. Same as previous, the self.conn.shutdown
check is there to make sure it's not called on unpatched luasec
deployments and self._tls is there to make sure we don't call shutdown()
on tcp sockets.
I wouldn't recommend logging of the conn:shutdown() error inside
close(), since a lot of clients simply close the connection before
SSL_shutdown() is done.
Attempt to fix a bug where connections are somehow closed twice, leading
to bad things happening elsewhere.
With LuaSec, closed connections are generally already too closed to
write anything to anyway since it does not support unidirectional
shutdown.
Prevent Bad Things from happening when the buffer gets full.
This of course opens up the possibility of intentionally killing
connections by sending much stuff, which need to be mitigated with rate
limits elsewhere.
Problem: The string slice operations when a lot of data gets buffered
ends up being expensive and memory-consuming. We have util.dbuffer for
precisely this kind of thing.
I want to keep the behavior of writebuffer being upgraded from nil to a
string to full buffer since the last step involves three table
allocations, where the previous buffer method only used one. Avoiding
those allocations for simple writes like white space keep alive feels
like it would keep memory churn down.
This work was started in 2020
This enables accepting admin stream socket (UNIX) connections trough the
same procedures as any other (TCP) socket, which avoids problems caused
by using the wrapclient API, which ends up discarding early data due to
only expecting early connection failure.
Fixes#1867
Allows creating listening sockets and accepting client connections
before Prosody starts.
This is unlike normal Prosody dynamic resource management, where ports
may added and removed at any time, and the ports defined by the config.
Weird things happen if these are closed (e.g. due to reload) so here we
prevent closing and ensure sockets are reused when opened again.
libunbound does not tell us the whole chain of CNAMEs, only the final
canonical name.
This is to aid in debugging since it will only be shown in the shell.
Handling signal events the same way as all other events makes sense and
seems safer than the signal handling just jumping around in C and
messing with Lua states.
This information is sometimes necessary in the context where we have a
connection that we know (or believe to be) associated with an incoming HTTP
request.
For example, it can be used to retrieve the IP address of a request (which may
differ from the IP address of the connection, due to X-Forwarded-For and co).
Thanks to the Jitsi team for highlighting this gap in the API.
This ensures that we support responses without a content-length header, and
allow streaming them through the streaming handler interface. An example of
such a response would be Server-Sent Events streams.
Unregistering the response before sending the trailer of the chunked
transfer encoding prevents opportunistic writes from being invoked and
running this code again when, which may cause an error when closing the
file handle a second time.
Normally the file size is known, so no chuck headers are sent.
add_defaults() is supposed to merge 3 tables, the defaults in
luaunbound, the defaults from prosody and any config from the prosody
config file. In the case where no `unbound={}` has been in the config,
it skips over the merge and returns only the prosody built-in defaults.
This results in libunbound skipping reading resolv.conf and uses its
default behavior of full recursive resolution.
Prior to #1737 there were only two tables, the luaunbound defaults and
the prosody config, where bypassing the merge and returning the former
did the right thing.
Fallback code for not having either the string.pack and string.unpack
functions available in Lua 5.4 or the struct lib is no longer needed
since the struct lib was imported as util.struct in 3ce3633527af
Otherwise requests with Connection: close would be stuck in the async
wait that starts after the handle_request() call.
Together with the new async debugging, this makes the async thread stay
in the set of waiting runners forever, where previously it would simply
be garbage collected.
