Explicitly states that RPC credentials grant full administrative access to the node and filesystem resources accessible by bitcoind. Adds a new section in JSON-RPC-interface.md to address issue #32274 by documenting that providing RPC credentials to untrusted clients
reopened #32424
P.S. I’ve tried to somehow squash all the commits from the previous pr but accidentally closed the pr and had no idea how to return back, therefore created a new pr, I’m really sorry for the inconvenience
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/33196.
See the guideline for information on the review process.
| Type | Reviewers |
|---|---|
| ACK | janb84 |
| Stale ACK | davidgumberg |
If your review is incorrectly listed, please copy-paste <!–meta-tag:bot-skip–> into the comment that the bot should ignore.
ACK 433954b6a5bd7480f7e05e58eafeac1dc6dfae7c
This PR adds information about security considerations when using RPC clients. Although bitcoin-core has done everything to minimise the risks of using RPC, it’s good to inform the user of the risks and the extra security precautions the user can take.
Informing the public about security risks and methods to mitigate them demonstrates responsible stewardship; therefore, I support this pull request.
134+ separate user accounts with restricted permissions) rather than relying solely on
135+ RPC access controls. While Bitcoin Core provides the `-rpcwhitelist` option to
136+ restrict which RPC commands specific users can access, and `-rpcwhitelistdefault`
137+ to control the default behavior for users without explicit whitelists, these should
138+ not be considered robust security boundaries, as users with access to certain
139+ commands may still be able to exploit functionality in unexpected ways.
bitcoind node is running on.
re ACK 938312d7a6dcf06cb401a16651e80320f36ee4db
Still think its a valuable addition. It introduces a clearer and stronger trust-boundary statement that is not explicitly documented elsewhere. To me, users should be informed about this so that they do not compromise their node’s security unknowingly.
Yes the paragraph is long and somewhat repetitive but it communicates the implications clearly, so that non (deeply) technical people should also understand the consequences of their actions in this.
Most relevant overlaps with this change:
docs/JSON-RPC-interface.md:L118-119:
docs/JSON-RPC-interface.md:L144-163
docs/init.md:L24
This password does not have to be remembered or typed as it is mostly used as a fixed token that bitcoind and client programs read from the configuration file, however it is recommended that a strong and secure password be used as this password is security critical to securing the wallet should the wallet be enabled.
If bitcoind is run with the “-server” flag (set by default), and no rpcpassword is set, it will use a special cookie file for authentication. The cookie is generated with random content when the daemon starts, and deleted when it exits. Read access to this file controls who can access it through RPC.
By default the cookie is stored in the data directory, but its location can be
overridden with the option -rpccookiefile. Default file permissions for the
cookie are “owner” (i.e. user read/writeable) via default application-wide file
umask of 0077, but these can be overridden with the -rpccookieperms option.
This allows for running bitcoind without having to do any manual configuration.
conf, pid, and wallet accept relative paths which are interpreted as
relative to the data directory. wallet only supports relative paths.
To generate an example configuration file that describes the configuration settings, see contrib/devtools/README.md.