https://bugzilla.redhat.com/show_bug.cgi?id=1020292
--- Comment #12 from Michael Hampton <error(a)ioerror.us> ---
(In reply to Warren Togami from comment #10)
Regarding selinux ...
/etc/bitcoin(/.*)?
gen_context(system_u:object_r:bitcoin_conf_t,s0)
/usr/bin/bitcoind --
gen_context(system_u:object_r:bitcoin_exec_t,s0)
/var/lib/bitcoin(/.*)?
gen_context(system_u:object_r:bitcoin_var_lib_t,s0)
1) Is this the only location where we want Bitcoin to have its configuration
and data files? It is also very common for users to run it where all of
this stuff is in ~/.bitcoin/
2) bitcoin-qt (using the ~/.bitcoin) is unconfined?
The only real interest that I have had expressed to me with respect to an
SELinux policy was for securing it when running as a service. Nobody has yet
expressed interest in having a policy for the GUI client, though I think this
is a good idea anyway.
3) Is it normal for packages to ship their own policy?
It's normal when there is no SELinux policy already existing upstream for the
package. For instance, see (possibly out of date)
https://fedoraproject.org/wiki/SELinux_Policy_Modules_Packaging_Draft
Ideally the policy should eventually go upstream into the reference policy/Red
Hat policy.
(In reply to Warren Togami from comment #11)
Currently bitcoind is not well suited to operate as a system
service.
The user's bitcoind as a RPC client could hypothetically operate to control
the system bitcoind, but that isn't true of the user's bitcoin-qt. This
makes operating bitcoind as a system service confusingly disjunct from the
user's bitcoind and bitcoin-qt. The user's bitcoind and bitcoin-qt are
meant to operate on the same data files and wallet while a system bitcoind.
It's been my experience that very few people who are interested in running a
system service also want to run the GUI client _on the same machine_. The usual
use case here is a service operator who wants his code to talk to bitcoind via
its API, and there's no GUI anywhere on the server. But, as you noted, bitcoind
isn't very well suited to run as a system service. The FHS compliance patch and
init script in my build address this, but not as well as could be done with
more extensive changes.
bitcoin 0.9 is planned to have key improvements that make it more
suitable
to use as system service.
I am definitely looking forward to this.
Perhaps bitcoin 0.8 as packaged should ...
* Include a README.FEDORA in %doc explaining the current state of the
package, how it is meant to be used.
This is a good idea and I'll put it in my next release.
* The entire selinux policy design should be thought through
carefully to be
able to handle the future expected uses of bitcoin.
* To handle today's normal use, the selinux policies should confine and
permit usage of the standard ~/.bitcoin directory in homedirs.
* Perhaps the selinux policy should additionally handle the system service
directories, even though it isn't commonly used yet. Would that within the
same policy weaken protection of the system service?
The SELinux policy definitely needs more eyeballs. It's functional for what it
does though. But I expect it will need some perhaps significant work for the
0.9 changes you alluded to, so I want to look at how 0.9 is shaping up first.
* For now do not include the .service file. That would misleadingly
suggest
that running it as a system service is the normal method of operation. Wait
until changes come in 0.9 then reassess the situation.
* Put the .service file in installed examples documented by README.FEDORA so
people know how to use the unsupported method of operation for now if they
really want it.
This is a problem because if we don't install the init script, we can't update
it later except by overwriting the user's manually installed init script. (And
I want to switch this out for a systemd unit file soon, which would still be a
pain for users to manually install. This will almost certainly wait for 0.9.)
And if we remove it, then existing installations break after updating. Bad news
both ways.
--
You are receiving this mail because:
You are on the CC list for the bug.