-
-
Notifications
You must be signed in to change notification settings - Fork 416
RPC Setup XMLRPC
Before continuing, it's worth mentioning that rTorrent methods are very flexible, and powerful, and can be used to execute arbitrary commands on your system. Think of exposing access to your rTorrent API as equivalent to exposing access to your system's shell.
You do not want your rTorrent XMLRPC API to fall into the wrong hands.
There are two ways to expose the XMLRPC endpoint for rTorrent:
You can:
✔️ Configure rTorrent to expose the endpoint to a local unix domain socket, for example ~/.local/rtorrent.sock
.
- You will then use a reverse proxy to publish this socket under some host, with some authentication mechanism set up.
- ✔️ This is considered more secure as local unix domain sockets can be assigned unix file read/write modes that can control which users on the system can & cannot access the API.
❌ Configure rTorrent to expose this socket on some address + port, eg localhost:5000
/127.0.0.1:5000
‼️ Never bind the SCGI port to anything but 127.0.0.1. Anyone who can send rTorrent XMLRPC commands does have the ability to execute code with the privileges of the user running rTorrent.⚠️ Even if you do bind this to localhost, publishing directly to a port is still less secure than publishing to a unix domain socket & proxying that- Directly publishing to localhost is less secure because any user on the localhost can access
localhost:5000
and use the API, thereby getting access to everything that the user that runs rTorrent has access to.
- Directly publishing to localhost is less secure because any user on the localhost can access
- ❌ In addition, you will most likely need to configure a reverse proxy to help publish your endpoint, so the convenience is not great.
This warning being said- Any time in this guide that you see rTorrent configured to publish to a local unix socket, and a reverse proxy configured to forward that, a similar effect could be achieved by directly publishing to a port, and the reverse proxy exposing that endpoint.
In rtorrent.rc
, the method network.scgi.open_port = 127.0.0.1:5000
may be used to publish directly to a port.
Without much further ado
What you need:
- rTorrent compiled / configured with the
--with-xmlrpc-c
flag -
scgi
for your reverse proxy:- http://python.ca/scgi/ for Apache 2.2,
- mod_proxy_scgi enabled for Apache 2.4,
- Lighttpd should have this built-in,
- recent versions of nginx have this built in.
- http://xmlrpc-c.sourceforge.net/ 1.00 or later, 1.07 or later for 64bit integer support.
You will be:
- Publishing the
xmlrpc
endpoint to a socket on the local filesystem, & setting user permissions on this socket to to restrict unauthorized user accounts on your computer from accessing it. - Proxying this socket to a network address + port, with some kind of authentication set up on your reverse proxy
network.scgi.open_local = /home/user/rtorrent/rpc.socket
# Set correct access rights to the socket file ----------+
# so both rTorrent & your reverse proxy can performed |
# read-write operations |
# but most users on the system can not v
schedule2 = scgi_permission,0,0,"execute.nothrow=chmod,\"g+w,o=\",/home/user/rtorrent/rpc.socket"
httpd.conf (2.2):
SCGIMount /RPC2 socket_path <TODO: Check syntax to mount Unix sockets>
httpd.conf (2.4):
ProxyPass /RPC2 scgi://localhost:9999 # SCGI network port
ProxyPass /RPC2 unix:///home/user/rtorrent/rpc.socket|scgi://localhost/ # SCGI Unix socket (2.4.7+)
lighttpd.conf:
server.modules += ( "mod_scgi" )
scgi.server = (
"/RPC2" =>
( "127.0.0.1" =>
(
"socket" => "/home/user/rtorrent/rpc.socket",
"check-local" => "disable",
"disable-time" => 0, # don't disable SCGI if connection fails
)
# YOU MUST ADD SOME KIND OF AUTH
)
)
Recent versions of nginx support SCGI by default
nginx.conf:
# This webserver is actually in a container that only publishes 8080 (container) -> localhost:8080 (host)
# IN reality, the http server should have TLS / SSL
# Achieving this with nginx, traefik, or the reverse proxy of your choice is well documented.
server {
listen 0.0.0.0:8080;
error_log ${CONFIG_DIR}/nginx/nginx.error.log;
access_log ${CONFIG_DIR}/nginx/access.log main;
auth_basic "Restricted";
# Users must log on with matching credentials
auth_basic_user_file ${NGINX_BASIC_AUTH_FILE};
location /RPC2 {
include scgi_params;
scgi_pass unix:${RTORRENT_SOCKET_PATH};
}
}
Do not forget, that on http://localhost:8008/RPC2 you will not see anything (through in rtorrent.error_log you will see something as upstream prematurely closed connection while reading response header from upstream, client: 192.168.93.104, server: nginx-rtorrent, request: "GET /RPC2 HTTP/1.1", upstream: "scgi://127.0.0.1:5000", host: "192.168.93.242:8008"
. It is XMLRPC, not a web service. You can test it with the xmlrpc
CLI tool (see later)).
SECURITY NOTE:
⚠️ use some basic auth, client certificate, SSO or any authentication method. Example for basic auth given above.⚠️ This config should also sit behind a TLS terminating proxy, so that user credentials are not sent unencrypted.- To put it another way, use
https
- To put it another way, use
It's worth mentioning that most clients do not provide support for authentication mechanisms besides basic auth, such as client certificates or SSO.
If any of your downloads have non-ASCII characters in the filenames, you must also set the following in rtorrent.rc
to force rTorrent to use the UTF-8 encoding. The XMLRPC standard requires UTF-8 replies, and rTorrent presently has no facilities to convert between encodings so it might generate invalid replies otherwise.
encoding.add = UTF-8
The web server will now route XMLRPC requests to rTorrent, which is listening only on connections from the local machine or on the local socket file. Also make sure the /RPC2 location is properly protected, (as in, has at least basic auth enabled, and is secured by SSL) and also name it differently to evade attackers probing for vulnerabilities (security through obscurity is not security, though this may reduce frequency of attempted exploits)
You may also use network.scgi.open_local = /foo/bar
to create a local domain socket, which supports file permissions. Set the read/write permissions of the directory the socket will reside in to only allow the necessary processes. This is the recommended way of using XMLRPC with rTorrent, though not all HTTP servers support local domain sockets for SCGI.
Access the XMLRPC interface using any XMLRPC-capable client. For example, using the xmlrpc
utility that comes with xmlrpc-c:
> # To list all the XMLRPC methods rTorrent supports.
> xmlrpc localhost:8008 system.listMethods
> # Get max upload rate.
> xmlrpc localhost:8008 throttle.global_up.max_rate ""
> # Set upload rate, exact 100000 bytes.
> xmlrpc localhost:8008 throttle.global_up.max_rate.set "" i/100000
> # Set upload rate, 100kb.
> xmlrpc localhost:8008 throttle.global_up.max_rate.set "" 100k
> # See list of downloads in "main" view
> xmlrpc localhost:8008 download_list ""
> # See list of downloads in "started" view
> xmlrpc localhost:8008 download_list "" started
> # Get uploaded bytes for specific download by info-hash
> xmlrpc localhost:8008 d.up.total e66e7012b8346271009110ac38f91bc0ad8ce281
> # Change the directory for a specific download.
> xmlrpc localhost:8008 d.directory.set 91A2DF0C9288BC4C5D03EC8D8C26B4CF95A4DBEF foo/bar/
> # Size of the first file in a specific download.
> xmlrpc localhost:8008 f.size_bytes 91A2DF0C9288BC4C5D03EC8D8C26B4CF95A4DBEF:f0
It supports both single strings akin to what the option file accepts, and proper XMLRPC integer, string and lists.
See the man page and the rtorrent/src/command_* source files for more details on what parameters some of the commands take.
Note that all commands now require a target, even if it is an empty string.
> xmlrpc localhost f.get_size_bytes 91A2DF0C9288BC4C5D03EC8D8C26B4CF95A4DBEF:f3
> xmlrpc localhost p.get_url 91A2DF0C9288BC4C5D03EC8D8C26B4CF95A4DBEF:p0
The first and second example passes the index of the file as an integer and string respectively. The third example uses a more compact syntax that contains both the info hash, type and index in the same string.
- Security review of all the webserver config snippets (specifically nginx)
- @matthewstrasiotto has improved nginx snippets, though I can't say whether I've done a thorough review.
- Use non-deprecated commands
- Unsure where deprecated commands have been used
- Use domain sockets, and only mention TCP in a warning
- Take out all the "you could" stuff that only confuses people (less options is more)
- I dot know if this is done