https://bugzilla.redhat.com/show_bug.cgi?id=1020292 --- Comment #12 from Michael Hampton <error@xxxxxxxxxx> --- (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. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review