From Fedora Project Wiki
RPM Package and SELinux
There probably should be two separate SELinux policy modules for the two different ways Bitcoin Core is used.
- User service bitcoind and graphical bitcoin-qt
- The most common way in which Bitcoin Core users run their own bitcoind or bitcoin-qt with is as a non-root user with datadir
~/.bitcoin/
. - There should be a separate user homedir SELinux policy for bitcoind and bitcoin-qt operated in this manner, with a context like
user_bitcoin_t
.- Note: Arbitrary other services may need to be granted both UNIX filesystem and SELinux permission to read the autotoken file from the user's ~/.bitcoin directory.
- The most common way in which Bitcoin Core users run their own bitcoind or bitcoin-qt with is as a non-root user with datadir
- System Service bitcoind
- bitcoind is not normally used as a system service but people want it to be packaged in this way. Perhaps this should be a sub-package like bitcoin-system-service. It would contain only the .service file, config, and README's.
- Should have its datadir somewhere like %{_datadir}bitcoinsys/ which expands to /var/lib/bitcoinsys/
- Config file
%config(noreplace) %{_datadir}/bitcoinsys/bitcoin.conf
with wallet disabled by default, but they could enable it with wallet=1 if they really want it. - With system username like:
bitcoinsys
- Wrapper should launch bitcoind in a context named like:
bitcoinsys_t
- %doc README-FEDORA-BITCOIN-SERVICE should probably explain how the service is meant to be configured, used and controlled with bitcoin-cli or RPC/REST interfaces as the non-default datadir does not match upstream documentation and it thus may be non-obvious to users.
Safety Requirements
- Wait for Bitcoin Core 0.12 for libsecp256k1.
Security Requirements
- Build Determinism/Reproducible Builds: Given identical inputs of source code and N-V-R's of dependencies in the buildroot, the binary output packaged must be identical when built by anyone.
- In this way anyone can verify that the binaries built on the Fedora buildsystem are not different from what should have been built from that source code. This allows for improved assurance that the build is not compromised.
- Medium-term goal: Also modify the .spec's of all library dependencies to make their builds reproducible.