systemd service script: set usable permissions on /etc/bitcoin config dir

sipsorcery commented at 8:42 pm on May 9, 2019: member

The current sample systemd script sets 0710 permissions on /etc/bitcoin which means it can only be read by the owner. If /etc/bitcoin does not exist when the systemd script is run for the first time then the directory gets created with root as the owner. The 0710 permissions will/may prevent a non-root user from being able to list the directory (on Ubuntu 18.04 the file can be listed but the permissions are inaccessible).

Even after copying bitcoin.conf to /etc/bitcoin it will remain unusable until either the directory permissions are changed or the service user is made the owner.

This PR adjusts the permissions that the service script will set on /etc/bitcoin so that all users can read and list the default config directory. A user will still have to copy the bitcoin.conf file to it but the adjustment will avoid them having to manually set permissions or change ownership of /etc/bitcoin.

In addition the ProtectHome option has been added. The rationale being if using a service to run bitcoind it’s more likely to be a headless daemon that should not need access to user home directories.

Best link I found for systemd [options].(https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ConfigurationDirectory=)

Fix systemd service file to set usable permissions on config directory. Additionally add protection for /home. c6d765c93b

DrahtBot added the label Scripts and tools on May 9, 2019

hebasto commented at 6:59 am on May 11, 2019: member

If /etc/bitcoin does not exist when the systemd script is run for the first time then the directory gets created…

Providing -conf=/etc/bitcoin/bitcoin.conf option in ExecStart=/usr/bin/bitcoind line of bitcoind.service file assumes setting up /etc/bitcoin/bitcoin.conf before bitcoind service get started.

The 0710 permissions will/may prevent a non-root user from being able to list the directory…

It looks good from the security point of view. Why is this an issue?

sipsorcery commented at 7:39 am on May 11, 2019: member

It looks good from the security point of view. Why is this an issue?

It’s now happened to me a couple of times where I’ve installed the service script and overlooked creating the config file. I then check the log messages realise it’s missing and copy it into the /etc/bitcoin directory. This is where the problem occurs. Restarting the bitcoin service will continue to fail because the permissions on /etc/bitcoin are incorrect.

2019-05-11T07:25:52Z

EXCEPTION: N5boost10filesystem16filesystem_errorE boost::filesystem::status: Permission denied: “/etc/bitcoin/bitcoin.conf” bitcoin in AppInit()

To fix the problem the ownership of /etc/bitcoin has to be changed to the user the service is running as. Unlike the StateDirectory directory the ownership of the ConfigurationDirectoryMode does not get updated automatically by systemd, from the [systemd reference]:(https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ConfigurationDirectory=):

Except in case of ConfigurationDirectory=, the innermost specified directories will be owned by the user and group specified in User= and Group=. If the specified directories already exist and their owning user or group do not match the configured ones, all files and directories below the specified directories as well as the directories themselves will have their file ownership recursively changed to match what is configured.

Another possible fix would be to remove the ConfigurationDirectoryMode directory from the script. That way at least the service script won’t create it with incorrect permissions and it will be left up to the user to do so as they see fit, most likely with themselves as the owner.

hebasto commented at 7:56 am on May 11, 2019: member

@sipsorcery

It’s now happened to me a couple of times where I’ve installed the service script and overlooked creating the config file.

IMO, there is nothing to fix in the software ;)

sipsorcery commented at 8:31 am on May 11, 2019: member

IMO, there is nothing to fix in the software ;)

Point taken and not disputed ;). Wish I could get my memory banks serviced. I keep cleaning them with alcohol but it just seems to make it worse :(.

For any other interested parties the choices I see are:

Leave as is and let users manually work out they need to set the ownership correctly on /etc/bitcoin. Once the ownership is set appropriately having systemd apply permissions on 0710 to the directory seems a good choice,
As per this PR set the permissions on /etc/bitcoin to 0755 and remove the need for users to set manually set the ownership of /etc/bitcoin/.

As a point of reference on my ubuntu system most configuration directories including /etc/ssh, /etc/systemd and /etc/tor have 0755 permissions and are owned by root.

ryanofsky approved

ryanofsky commented at 9:42 pm on May 13, 2019: member

utACK c6d765c93be1240d66bea35992dfe4688b00e741

Restarting the bitcoin service will continue to fail because the permissions on /etc/bitcoin are incorrect.

This does seem like an annoyance worth fixing, and I think the current PR changing permissions from:

0drwx--x--- root root /etc/bitcoin

0drwxr-xr-x root root /etc/bitcoin

0710 -> 0755 seems fine. Other options would be 0711:

0drwx--x--x root root /etc/bitcoin

Or to keep the current 0710 but change the group:

0drwx--x--- root bitcoin /etc/bitcoin

with something like:

0PermissionsStartOnly=true
1ExecStartPre=chgrp bitcoin /etc/bitcoin

laanwj commented at 12:45 pm on July 4, 2019: member

I’m not convinced that this is a good idea. bitcoin.conf can contain secrets such as RPC account user/passwords, so restricting its permissions to root and whatever the uid/gid is that the service runs under makes sense. (at least by default! of course admins can decide to weaken these permissions in specific cases)

sipsorcery commented at 12:54 pm on July 4, 2019: member

@laanwj the PR doesn’t affect the permissions on the bitcoin.conf file. It affects the permissions that systemd will set on the /etc/bitcoin directory IF it does not exist. If the bitcoin.conf file has restricted read permissions they are not affected.

hebasto commented at 6:26 pm on July 5, 2019: member

Concept NACK.

Rationale:

If the /etc/bitcoin directory was created by systemd with root ownership and 0755 permissions, the just created bitcoin.conf file (e.g., touch /etc/bitcoin/bitcoin.conf) will acquire the same permissions. It means bitcoin.conf will be readable for all users.
This PR looks like a bad trade-off between first-time setup convenience for long-term security.
The best practice is:

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. @sipsorcery the PR doesn’t affect the permissions on the bitcoin.conf file.

Yes, it does. It affects the permissions on the bitcoin.conf file indirectly as described above.

sipsorcery commented at 7:11 pm on July 5, 2019: member

Ok I’ll accept that the proposed solution is not ideal and close this PR.

In my defense I will point out that my goal was to avoid future users of the sample systemd bitcoind.service script receiving the error below. I reasoned that if I, as a someone with a bit of programmer experience under my belt, was having difficulties then so would others that tried to use the script. That could certainly be a wrong assumption.

This is the error that occurs if I take the same steps I’ve use to set up dozens of systemd services on Ubuntu.

 0~$ tail /var/lib/bitcoind/debug.log -f
 12019-07-05T18:43:54Z Using data directory /var/lib/bitcoind
 22019-07-05T18:43:54Z
 3
 4************************
 5EXCEPTION: N5boost10filesystem16filesystem_errorE
 6boost::filesystem::status: Permission denied: "/etc/bitcoin/bitcoin.conf"
 7bitcoin in AppInit()
 8
 92019-07-05T18:43:54Z Shutdown: In progress...
102019-07-05T18:43:54Z Shutdown: done

@hebasto You are right*. *Unless the bitcoin.conf file already exists with the correct ownership. From the systemd manual:

Except in case of ConfigurationDirectory=, the innermost specified directories will be owned by the user and group specified in User= and Group=. If the specified directories already exist and their owning user or group do not match the configured ones, all files and directories below the specified directories as well as the directories themselves will have their file ownership recursively changed to match what is configured. As an optimization, if the specified directories are already owned by the right user and group, files and directories below of them are left as-is, even if they do not match what is requested. The innermost specified directories will have their access mode adjusted to the what is specified in RuntimeDirectoryMode=, StateDirectoryMode=, CacheDirectoryMode=, LogsDirectoryMode= and ConfigurationDirectoryMode=.

There’s too much beer to drink to worry about 710 || 755 :).

sipsorcery closed this on Jul 5, 2019

setpill commented at 12:01 pm on August 6, 2019: contributor

Just stumbled across this same issue and contributed my own fix with 711 (rather than 755). On the one hand I see the problem with having the config file world-readable due to RPC secrets; on the other hand, if one wants to run with the default settings and doesn’t care about putting a bitcoin.conf in /etc/bitcoin the current systemd service file simply creates the the directory with the wrong permissions. I think @ryanofsky’s chgrp suggestion is the best of both worlds, will experiment with that and update my PR if it works.

setpill commented at 2:38 pm on August 6, 2019: contributor

I disagree with some points made in this discussion. @hebasto

Providing -conf=/etc/bitcoin/bitcoin.conf option in ExecStart=/usr/bin/bitcoind line of bitcoind.service file assumes setting up /etc/bitcoin/bitcoin.conf before bitcoind service get started.

False; this just sets the location where bitcoind will look for the configuration; bitcoind does not require the config file. Without -conf=/etc/bitcoin/bitcoin.conf, bitcoind would default to iiuc $HOME/.bitcoin/bitcoin.conf (with $HOME set by the bitcoin user), preventing further hardening measures such as ProtectHome=true (assuming the bitcoin user’s home dir is /home/bitcoin).

The best practice is: 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.

This looks like it might also need fixing; there is no point to separating the config file out from the writeable datadir if you are going to make the config dir writeable by the user executing the service; making the config file readable but not writeable by the user executing the service is the whole point of having separate data- and config dirs; this is also why systemd does not chown the ConfigurationDirectory to the User and Group specified in the service file.

DrahtBot locked this on Dec 16, 2021

systemd service script: set usable permissions on /etc/bitcoin config dir #15995