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?

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.

@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 ;)

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:

1. 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,

2. 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.

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)

@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.

Concept NACK.

Rationale:

1. 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.

2. This PR looks like a bad trade-off between first-time setup convenience for long-term security.

3. 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.

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.

~$ tail /var/lib/bitcoind/debug.log -f
2019-07-05T18:43:54Z Using data directory /var/lib/bitcoind
2019-07-05T18:43:54Z

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

2019-07-05T18:43:54Z Shutdown: In progress...
2019-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 :).

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.

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).

3. 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.