Hide Forgot
Description of problem: Upstream version of BIND requires directory used in option directory to be writeable. It would not even start with read-only directory. That was changed by our downstream patch. This required workaround in bug #1315821. It affects also bug #1452091, where no workaround exists. Proposed change were refused by upstream [1], stating this is our packaging issue. [1] https://bugs.isc.org/Public/Bug/Display.html?id=46242
Fixed would be also errors reported in bug #1435883. It can be used for testing. It requires writeable working directory, because their path is not overriden by default configuration. Just start any named service and run "rndc secroots" or "rndc recursing".
A commit [0] claiming to fix this RHEL7 bug was pushed in Fedora with this: Requires(post): policycoreutils-python This is wrong, please use: Requires(post): python2-policycoreutils Or: Requires(post): python3-policycoreutils explicitly on Fedora. See the guidelines [1]. [0] https://src.fedoraproject.org/rpms/bind/c/e3d0b186d1ab32d4a628aff57752778cd4833cb8?branch=master [1] https://fedoraproject.org/wiki/Packaging:Python#Dependencies
(In reply to Miro Hrončok from comment #13) > A commit [0] claiming to fix this RHEL7 bug was pushed in Fedora with this: > > Requires(post): policycoreutils-python > > This is wrong, please use: > > Requires(post): python2-policycoreutils > > Or: > > Requires(post): python3-policycoreutils > > explicitly on Fedora. See the guidelines [1]. > > [0] > https://src.fedoraproject.org/rpms/bind/c/ > e3d0b186d1ab32d4a628aff57752778cd4833cb8?branch=master > [1] https://fedoraproject.org/wiki/Packaging:Python#Dependencies Hi Miro, I made a quick backport of this commit into Fedora. I am sorry I missed different product in commit message. I also missed change in policycoreutils-python made later in Fedora. It requires utility binaries, not python modules left in python?-policycoreutils. It was corrected by commit [1] in Fedora. 1. https://src.fedoraproject.org/rpms/bind/c/3159fb6a8e3b33377726cec98cbe9e34cb0e78b5?branch=master
Thanks.
Created attachment 1485216 [details] Fix when selinux-policy-targeted is missing
Comment on attachment 1485216 [details] Fix when selinux-policy-targeted is missing Pavel, can you please review the changes? Thank you
Comment on attachment 1485216 [details] Fix when selinux-policy-targeted is missing I'd prefer #c11 but once it's too late the patch looks good. Small thing: in post section there're two branches covered upgrade (one explicitly with [$1 -gt 1] and another one in else section below, shouldn't they be merged? Besides of that %selinux_set_booleans on upgrade are called twice in %post and %posttrans section.
I have found some issues with %selinux_set_booleans macro, reported as bug #1631814. It expects selinux_set_booleans is called exactly the same time as selinux_unset_booleans or it will not reset it back to original value. So current patch would not work as expected. In %postun unset should be called always. In case of upgrade from version without boolean setting, old %postun would be called where unset is not yet present. When upgrading from version with boolean setting, boolean would be unset between %postun of removed and %posttrans of new package. If upgraded service was running before, it would be running for some time without write access. I think selinux_set_booleans should be always called in posttrans. Bind will be able to start anyway with read-only support for home back inside. In the time between %postun of old bind package and before %posttrans will have chance to fail some operations. Namely NTA modification and addzone or delzone changes might fail. Depending on configuration also some other dumps. That may never happen in case of anaconda install, named is not yet enabled and started.
(In reply to Pavel Zhukov from comment #24) > Comment on attachment 1485216 [details] > Fix when selinux-policy-targeted is missing > > I'd prefer #c11 but once it's too late the patch looks good. > Small thing: in post section there're two branches covered upgrade (one > explicitly with [$1 -gt 1] and another one in else section below, shouldn't > they be merged? Besides of that %selinux_set_booleans on upgrade are called > twice in %post and %posttrans section. Of course it should be merged into else branch. I did not spot that. But as I found in comment #25, it does count sets and unset and their number should match. For that reason, it should not even be inside if.
Just thinking, if on upgrade in %post it is set once more (to be set before %posttrans of new package again), it has to call two times unset in %postun. One should be called always, one only for upgrades. It would called by then set of old package in %posttrans and also already %post of the new package. It can see one problem with it. %postun of old package relies on fact %post of new package will set it. If we stop setting it and I hope we would, it would unset one more time than it was set. I cannot think a way to solve it. Support for read-only home is mandatory. My conclusion is to use just one set in %posttrans and one unset in %post. Their order should be correct, because %post of old package is called on upgrade. That means such old package already passed %posttrans before. And selinux-policy should be changed to not require setting the boolean in the first place, because it is quite complicated without it.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:3136