When an SCGI client closes the connection before rtorrent finishes sending
the response, send() in SCgiTask::event_write() returns -1 with errno EPIPE.
EPIPE was grouped with EAGAIN/EINTR as a non-fatal retry-later condition, so
the task was not closed and its descriptor stayed registered for EPOLLOUT. A
broken socket is reported writable immediately, so epoll_wait() returns it on
every iteration and the SCGI thread spins at 100% CPU on one core
indefinitely. The dead connection fd is also leaked (stays ESTAB).
EPIPE is terminal here, not retryable: the peer is gone and the response can
never be delivered. Close the task on EPIPE, matching event_read(), which
already closes on any recv() error other than EAGAIN/EINTR.
Reproduction: open the SCGI socket, send a complete RPC request, then
shutdown(SHUT_RDWR)/close before reading the reply. Stock: the rtorrent-scgi
thread goes to 100% CPU and the connection leaks. With this change: CPU stays
at 0% and the descriptor is closed.
detect_content_type() peeked at m_buffer[m_body] to infer JSON vs XML
when no CONTENT_TYPE header was provided. When the TCP header segment
arrives without any body bytes, m_body equals m_position and the peek
reads the null terminator padding byte — not the actual '{' or '[' —
causing JSON requests to be incorrectly classified as XML and fail.
Fix:
- Remove the body peek from detect_content_type(); defer it to after
the full body is confirmed present in event_read().
- Add a m_content_type_set flag to distinguish header-provided type
from auto-detected type.
SCgiTask objects are pre-allocated in a pool (scgi.cc) and reused across
SCGI connections. SCgiTask::open() did not reset m_trusted, so when a
task that had handled an untrusted connection (m_trusted=false) was
reused for a new connection, m_trusted stayed false unless the new
connection explicitly sent UNTRUSTED_CONNECTION=1.
The header parser only set m_trusted=false on value 1 and was a no-op
on value 0 (the comment said "default is trusted, so do nothing") —
which is wrong for a reused task that is no longer in default state.
This caused intermittent rejection of trusted commands (e.g. ruTorrent
calling execute.capture for UID detection) with "Command X is not allowed
for untrusted connections", producing cascading plugin failures and
"ruTorrent cannot determine the UID of rTorrent user" in the web UI.
Fix:
- SCgiTask::open() resets m_trusted=true to default.
- parse_headers explicitly sets m_trusted=true on UNTRUSTED_CONNECTION=0,
so the value sent on the wire is authoritative regardless of pool
reuse semantics.
Verified on gb4 with rtorrent 0.16.11 + this fix: 30/30 trusted calls
succeed, 30/30 untrusted correctly blocked, 30/30 trusted-after-untrusted
batch all succeed (previously 70%+ would fail in the same scenario).
1. network.rpc.use_xmlrpc and network.rpc.use_jsonrpc: change from
CMD2_VAR_BOOL_U (getter+setter both safe) to CMD2_VAR_BOOL_U_GET
(getter safe, setter trusted-only). Untrusted callers could
previously disable RPC transports entirely.
2. Remove broad catch(std::exception&) and catch(...) from xmlrpc_c.cc
that masked real defects and altered fault semantics.
3. Revert SCGI callback catch-all to re-throw instead of swallowing
exceptions with a generic error response.
Root cause: network.rpc.use_xmlrpc and network.rpc.use_jsonrpc were not
marked as untrusted-safe, but RpcManager::process() calls them before
dispatching to the protocol handler. When an untrusted request arrived,
call_command() threw untrusted_error for these gatekeepers, which escaped
the callback_interrupt_pollling callback and crashed rtorrent.
Fix: Mark network.rpc.use_xmlrpc/jsonrpc as safe (CMD2_VAR_BOOL_U).
Also harden exception safety:
- SCGI callback catch-all now sends a generic error response instead of
re-throwing, since the callback infrastructure may not support
exception propagation.
- xmlrpc_c.cc now has catch(std::exception&) and catch(...) safety nets
after the specific exception handlers.
Replace the v2 blacklist approach with a per-command flag system.
Commands must opt in to being available for untrusted connections
via flag_untrusted_safe (0x400), checked in call_command() which
catches all execution paths including nested commands.
Infrastructure changes:
- Add flag_untrusted_safe to CommandMap
- Add untrusted_error exception type for proper error codes
- Enforce trust check in both call_command() overloads
- Add catch blocks in xmlrpc_c, xmlrpc_tinyxml2, and jsonrpc handlers
- Port SCGI trust state management from v2 (thread_local, header parsing)
- Add _U macro variants in command_helpers.h for safe command registration
- Add CMD2_VAR_*_U and CMD2_VAR_*_U_GET variants for variables
Inline nlohmann/json for the JSON parsing itself, and handle requests
with the same SCGI interface as XML-RPC.
Based off the work in https://github.com/jesec/rtorrent
This is a follow up to #1310. Apple and Solaris do not support MSG_NOSIGNAL, so disable this flag for these platforms until we find a better solution. Other platforms remain unaffected.
This commit resolves a scgi software crash when the scgi socket is closed before the message can be sent. It instructs `::send()` not to send a SIGPIPE termination signal. Instead the value -1 is returned and handled bellow. The SCgiTask is closed and a new one is sent to complete the task.
```
Thread 3 "rtorrent scgi" received signal SIGPIPE, Broken pipe.
[Switching to Thread 0x7fffe635c6c0 (LWP 2443872)]
0x00007ffff7929a84 in send () from /lib/x86_64-linux-gnu/libc.so.6
```
* Fixed a bad conditional that would result in write syscall being called with -1 for logging executing external commands.
git-svn-id: svn://rakshasa.no/libtorrent/trunk/rtorrent@1201 e378c898-3ddf-0310-93e7-cc216c733640
* Cleaned up the Command stack implementation.
* Added framework for object_storage class that will hold variables and user-defined command lists.
git-svn-id: svn://rakshasa.no/libtorrent/trunk/rtorrent@1162 e378c898-3ddf-0310-93e7-cc216c733640
* Cleaned up main initialization, SCGI and polling code.
* Fixed a bug that would cause reading of a piece to hang if the incoming data contains only data up to the file boundary, but not the next file's data. The bug did not trigger if the file boundary and piece boundaries were the same.
git-svn-id: svn://rakshasa.no/libtorrent/trunk/rtorrent@1101 e378c898-3ddf-0310-93e7-cc216c733640
* Added 'd.get_bitfield' command for retrieving the bitfield in hex format. Patch by Thomas Rosner. (PD)
* Fixed include headers for gcc-4.4.0. Patch by 'kloeri'.
* Switched a 'long long' with 'int64_t' in xmlrpc.cc to avoid incompatible types for some systems.
git-svn-id: svn://rakshasa.no/libtorrent/trunk/rtorrent@1092 e378c898-3ddf-0310-93e7-cc216c733640
rakshasa