Rationale: ran into a bug with the systemd service file, fixed it locally and figured I might as well contribute my fix.
Also fixed some unrelated confusing phrasing in the comments of the same file, after discussion in IRC.
Rationale: ran into a bug with the systemd service file, fixed it locally and figured I might as well contribute my fix.
Also fixed some unrelated confusing phrasing in the comments of the same file, after discussion in IRC.
tACK ~6c8b98b5bf8c3e6c797544b2c7f0a0fc5f5afda6~ 74f741d49c3763d082fc15fda7f342515faf4210 (read the commits in the wrong date order)
Since this has cropped up again IMHO either something like the fix in this PR should be merged or if not maybe we should at least add an extra step to the documentation informing users they MUST always explicitly set the ownership on the /etc/bitcoin directory.
The doc/init.md file states:
The configuration file, PID directory (if applicable) and data directory should all be owned by the bitcoin user and group. It is advised for security reasons to make the configuration file and data directory only readable by the bitcoin user and group. Access to bitcoin-cli and other bitcoind rpc clients can then be controlled by group membership.
NOTE: When using the systemd .service file, the creation of the aforementioned directories and the setting of their permissions is automatically handled by systemd. Directories are given a permission of 710, giving the bitcoin group access to files under it if the files themselves give permission to the bitcoin group to do so (e.g. when -sysperms is specified). This does not allow for the listing of files under the directory.
The problem is this sentence When using the systemd .service file, the creation of the aforementioned directories and the setting of their permissions is automatically handled by systemd. At least on Ubuntu 18.04 it's wrong. If the creation of the /etc/bitcoin directory is left up to systemd the result is:
$ sudo ls -l /etc
drwx--x--- 2 root root 4096 Aug 17 12:34 bitcoin
$ sudo ls -l /etc/bitcoin
-rw-r--r-- 1 bitcoin bitcoin 6455 Aug 17 12:34 bitcoin.conf
Which results in:
sudo systemctl start bitcoind
2019-08-17T12:58:29Z Bitcoin Core version v0.18.1 (release build)
2019-08-17T12:58:29Z Assuming ancestors of block 0000000000000000000f1c54590ee18d15ec70e68c8cd4cfbadb1b4f11697eee have valid signatures.
2019-08-17T12:58:29Z Setting nMinimumChainWork=0000000000000000000000000000000000000000051dc8b82f450202ecb3d471
2019-08-17T12:58:29Z Using the 'sse4(1way),sse41(4way),avx2(8way)' SHA256 implementation
2019-08-17T12:58:29Z Using RdSeed as additional entropy source
2019-08-17T12:58:29Z Using RdRand as an additional entropy source
2019-08-17T12:58:29Z Default data directory /home/admin/.bitcoin
2019-08-17T12:58:29Z Using data directory /var/lib/bitcoind
2019-08-17T12:58:29Z
************************
EXCEPTION: N5boost10filesystem16filesystem_errorE
boost::filesystem::status: Permission denied: "/etc/bitcoin/bitcoin.conf"
bitcoin in AppInit()
************************
EXCEPTION: N5boost10filesystem16filesystem_errorE
boost::filesystem::status: Permission denied: "/etc/bitcoin/bitcoin.conf"
bitcoin in AppInit()
2019-08-17T12:58:29Z Shutdown: In progress...
2019-08-17T12:58:29Z Shutdown: done
The fix is:
$ sudo chown bitcoin:bitcoin /etc/bitcoin
$ ls -l /etc
drwx--x--- 2 bitcoin bitcoin 4096 Aug 17 12:34 bitcoin
sudo systemctl start bitcoind
2019-08-17T13:09:13Z Bitcoin Core version v0.18.1 (release build)
2019-08-17T13:09:13Z Assuming ancestors of block 0000000000000000000f1c54590ee18d15ec70e68c8cd4cfbadb1b4f11697eee have valid signatures.
2019-08-17T13:09:13Z Setting nMinimumChainWork=0000000000000000000000000000000000000000051dc8b82f450202ecb3d471
2019-08-17T13:09:13Z Using the 'sse4(1way),sse41(4way),avx2(8way)' SHA256 implementation
2019-08-17T13:09:13Z Using RdSeed as additional entropy source
2019-08-17T13:09:13Z Using RdRand as an additional entropy source
2019-08-17T13:09:13Z Default data directory /home/bitcoin/.bitcoin
2019-08-17T13:09:13Z Using data directory /var/lib/bitcoind
2019-08-17T13:09:13Z Config file: /etc/bitcoin/bitcoin.conf
2019-08-17T13:09:13Z Using at most 125 automatic connections (1024 file descriptors available)
2019-08-17T13:09:13Z Using 16 MiB out of 32/2 requested for signature cache, able to store 524288 elements
2019-08-17T13:09:13Z Using 16 MiB out of 32/2 requested for script execution cache, able to store 524288 elements
2019-08-17T13:09:13Z Using 4 threads for script verification
2019-08-17T13:09:13Z HTTP: creating work queue of depth 16
2019-08-17T13:09:13Z No rpcpassword set - using random cookie authentication.
2019-08-17T13:09:13Z Generated RPC authentication cookie /var/lib/bitcoind/.cookie
2019-08-17T13:09:13Z HTTP: starting 4 worker threads
2019-08-17T13:09:13Z scheduler thread start
2019-08-17T13:09:13Z Using wallet directory /var/lib/bitcoind
2019-08-17T13:09:13Z init message: Verifying wallet(s)...
2019-08-17T13:09:13Z Using BerkeleyDB version Berkeley DB 4.8.30: (April 9, 2010)
2019-08-17T13:09:13Z Using wallet /var/lib/bitcoind
2019-08-17T13:09:13Z BerkeleyEnvironment::Open: LogDir=/var/lib/bitcoind/database ErrorFile=/var/lib/bitcoind/db.log
2019-08-17T13:09:13Z init message: Loading banlist...
2019-08-17T13:09:13Z ERROR: DeserializeFileDB: Failed to open file /var/lib/bitcoind/banlist.dat
2019-08-17T13:09:13Z Invalid or missing banlist.dat; recreating
2019-08-17T13:09:13Z Cache configuration:
2019-08-17T13:09:13Z * Using 2.0 MiB for block index database
2019-08-17T13:09:13Z * Using 8.0 MiB for chain state database
2019-08-17T13:09:13Z * Using 440.0 MiB for in-memory UTXO set (plus up to 286.1 MiB of unused mempool space)
2019-08-17T13:09:13Z init message: Loading block index...
2019-08-17T13:09:13Z Opening LevelDB in /var/lib/bitcoind/blocks/index
2019-08-17T13:09:13Z Opened LevelDB successfully
@sipsorcery 6c8b98b is potentially dangerous; see #15995 (comment) (quoted below for ease of reading).
I'm not convinced that this is a good idea.
bitcoin.confcan contain secrets such as RPC account user/passwords, so restricting its permissions torootand whatever theuid/gidis that the service runs under makes sense. (at least by default! of course admins can decide to weaken these permissions in specific cases)
I have since changed the PR to, rather than make the conf dir/file world-readable, make systemd set the group of the confdir to bitcoin as per #15995#pullrequestreview-236934507 (relevant part quoted below):
Other options would be [..] to keep the current 0710 but change the group:
drwx--x--- root bitcoin /etc/bitcoinwith something like:
PermissionsStartOnly=true ExecStartPre=chgrp bitcoin /etc/bitcoin
As well as included the hardening from your PR (ProtectHome).
utACK 74f741d49c3763d082fc15fda7f342515faf4210. Looks good to me, but please rebase and drop the first commit (6c8b98b5bf8c3e6c797544b2c7f0a0fc5f5afda6). It's confusing to keep that commit when the change it makes is just reverted later by the third commit (eeb046abb8187da85e6e6f6570c06e9620595d5a).
The phrasing seemed to indicate that the options specified in
ExecStart= could not be specified in the config file, necessitating
their inclusion in the service file. However, the options in the
config file simply get overridden by any specified in ExecStart=.
Rather than making the config dir world-readable, which potentially
leaks RPC credentials, the group of the directory is changed to the one
the service is executed as.
Further hardening; the service should be run with as many restrictions
as possible without breaking it.
The bitcoin user needs read access to the configuration file, but write
access is not needed. It is not considered best practice to make
configuration directories and files owned by the services reading them.
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--174a7506f384e20aa4161008e828411d-->
No conflicts as of last run.
utACK f3b57f4a1c17aadbf02d408e980490c88838c6ba. Only change since last review is removing ConfigurationDirectoryMode churn in early commits
@sipsorcery @dongcarl Want to take another look here?
tACK f3b57f4a1c17aadbf02d408e980490c88838c6ba (nothing changed since previous tACK).
FWIW, PermissionsStartOnly, introduced in this PR, is deprecated.