Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 601510 - net-dns/bind-9.10.4_p4 (OpenRC): pidfile issues (can make an selinux enabled system unusable)
Summary: net-dns/bind-9.10.4_p4 (OpenRC): pidfile issues (can make an selinux enabled ...
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High major (vote)
Assignee: Christian Ruppert (idl0r)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-12-03 11:40 UTC by Alexander Wetzel
Modified: 2017-05-21 10:53 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
patch to /etc/init.d/named (named.patch,1.15 KB, patch)
2016-12-03 11:40 UTC, Alexander Wetzel
Details | Diff
patch to /etc/init.d/named (named.diff,2.37 KB, patch)
2017-05-21 10:38 UTC, Alexander Wetzel
Details | Diff
patch to /etc/init.d/named (named_2.diff,2.45 KB, patch)
2017-05-21 10:53 UTC, Alexander Wetzel
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Wetzel 2016-12-03 11:40:48 UTC
Created attachment 454966 [details, diff]
patch to /etc/init.d/named

I'm setting up a chrooted net-dns/bind-9.10.4_p4 on gentoo hardened with selinux and found some issues with the init script which seems rather generic and not related to the hardened platform. 

I've attached a patch what I had to change in the init script to get it working, here what the changes are and why they seem to be necessary:

1) uninitialized use of "piddir" in the start function:
The variable is used in the checkpath call in line 158. Since it's unset at this stage it checkpath will use the root dir for this action. 
That is in fact basically nuking an selinux system running in strict, since it will for some reason change the type of "/" to "default_t", causing strange issues till it has been set to the correct type again. I fixed that by moving the lines setting the variable to the top of the function. 

2) Different pidfile locations checked for start and stop calls, making it impossible to stop the service normally:
As default we have this as suggestion in /etc/conf.d/named:
 PIDFILE="${CHROOT}/run/named/named.pid"
(Now I'm not sure if the default really was /run and not /var/run instead, but that is irrelevant here)

Therefore PIDFILE will be set to "/chroot/dns/run/named/named.pid" if we enable chroot and keep the defaults.
But for some - for me incomprehensible reason - the start-stop-deamon call in line 177 is using this path relative to the chroot root. Since the path does not exist in an (auto-setup) chroot no pid file will be created. Named still starts for me, but can't be stopped/restarted via the normal tools.

So I changed PIDFILE to PIDFILE="/run/named/named.pid" in /etc/conf.d/named.
This fixes the pidfile creation, but it still can't be stopped via e.g. "service named stop", since the stop function is now checking relative to the real root. I worked around that by prepending ${CHROOT} to line 205.

Of course these changes may have undesired side effects on other installs and it also seems to be bad practice to set PIDFILE to a value which will not point to the real pidfile. The correct fix s therefore probably something different...

To summarize, I have fixed my problems by:
1) modifying /etc/init.d/named as shown in the attached patch
2) setting PIDFILE in /etc/conf.d/named to PIDFILE="${CHROOT}/run/named/named.pid"

With those changes I can now start and stop named normally.
Comment 1 Alexander Wetzel 2016-12-03 11:53:29 UTC
Sorry, found a C&P error in the initial report:

Of course ${CHROOT} must NOT be used in PIDFILE in the description above:

Here the fixed paragraph:

To summarize, I have fixed my problems by:
1) modifying /etc/init.d/named as shown in the attached patch
2) setting PIDFILE in /etc/conf.d/named to PIDFILE="/run/named/named.pid"
Comment 2 jack_mort 2017-05-03 15:41:09 UTC
Hi,
Last part of the patch (the hack to stop function) is not working for me.
I had to remove it and revert to original line.
Comment 3 Alexander Wetzel 2017-05-21 10:38:00 UTC
Created attachment 473630 [details, diff]
patch to /etc/init.d/named

I tried my hand on a proper fix, but this is getting complex fast...

It started out with the idea to also bind mount /run/named in the chroot environment, so the same pid file is visible in the normal environment and the chrooted one. With this patch all reverences to the pidfile must be done ignoring the chroot path suffix.

I would suggest to not set the pidfile in /etc/conf.d/named at all and only define it in /etc/bind/named.conf. 
Also try to stick to the default "/run/named/named.pid", since many other cases may well need adoptions to the chroot environment. And keep in mind that the pid directory will be accessible from the chrooted environment...

(When you are running also selinux you have to make make sure the chroot env is  correct labeled, which included to have the mount points labeled as "mnt_t")

Short summary of the changes compared to the current official script:
- It initializes piddir prior to calling checkpath with the variable (So we don't operate on the system root, with serious impact on selinux systems.)

- The pid directory is bind mounted to the chroot environment (So the pid file created on start in the chroot environment is also found in the expected location whenn calling stop)

- It handles multiple "/" in mountpoint paths. (This allows the chroot path to terminate with "/" and still umount the pid dir properly)

- /usr/sbin/named-checkconf is now extracting the pid-dir variable from /etc/bind/named.conf, not from the chrooted file. (Allows us to call _get_pidfile prior to the bind mounts. Allows us to autodetect which directory must be mounted to the chroot env for the pid file.)
Comment 4 Alexander Wetzel 2017-05-21 10:53:16 UTC
Created attachment 473634 [details, diff]
patch to /etc/init.d/named

uploaded correct version of patch