Bug 1569466 (named_writable_home) - named: /var/named does not allow writing temporary files by daemon
Summary: named: /var/named does not allow writing temporary files by daemon
Keywords:
Status: CLOSED ERRATA
Alias: named_writable_home
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: bind
Version: 7.6
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: rc
: ---
Assignee: Petr Menšík
QA Contact: Petr Sklenar
URL:
Whiteboard:
Depends On: 1572647 1633158
Blocks: 1315821 1435883 1452091
TreeView+ depends on / blocked
 
Reported: 2018-04-19 10:33 UTC by Petr Menšík
Modified: 2018-10-30 10:19 UTC (History)
6 users (show)

Fixed In Version: bind-9.9.4-65.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1588592 (view as bug list)
Environment:
Last Closed: 2018-10-30 10:18:33 UTC
Target Upstream Version:


Attachments (Terms of Use)
Fix when selinux-policy-targeted is missing (3.55 KB, patch)
2018-09-20 16:30 UTC, Petr Menšík
pzhukov: review+
Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1572647 0 medium CLOSED BIND is not able to write into home 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1580389 0 unspecified CLOSED bind-dyndb-ldap post script enables setsetbool named_write_master_zones on installation 2021-02-22 00:41:40 UTC
Red Hat Product Errata RHBA-2018:3136 0 None None None 2018-10-30 10:19:49 UTC

Internal Links: 1572647 1580389

Description Petr Menšík 2018-04-19 10:33:46 UTC
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

Comment 6 Petr Menšík 2018-05-30 13:32:18 UTC
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".

Comment 13 Miro Hrončok 2018-06-19 09:17:06 UTC
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

Comment 15 Petr Menšík 2018-09-04 12:02:26 UTC
(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

Comment 16 Miro Hrončok 2018-09-04 12:54:19 UTC
Thanks.

Comment 22 Petr Menšík 2018-09-20 16:30:34 UTC
Created attachment 1485216 [details]
Fix when selinux-policy-targeted is missing

Comment 23 Tomáš Hozza 2018-09-21 08:18:15 UTC
Comment on attachment 1485216 [details]
Fix when selinux-policy-targeted is missing

Pavel, can you please review the changes? Thank you

Comment 24 Pavel Zhukov 2018-09-21 14:59:42 UTC
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.

Comment 25 Petr Menšík 2018-09-21 17:41:54 UTC
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.

Comment 26 Petr Menšík 2018-09-21 17:45:57 UTC
(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.

Comment 27 Petr Menšík 2018-09-21 17:57:28 UTC
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.

Comment 32 errata-xmlrpc 2018-10-30 10:18:33 UTC
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


Note You need to log in before you can comment on or make changes to this bug.