Bug 10994 - Startup script remount the chroot at each restart even the mount is already done
Summary: Startup script remount the chroot at each restart even the mount is already done
Status: RESOLVED WONTFIX
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Guillaume Rousse
QA Contact:
URL:
Whiteboard: MGA5TOO
Keywords: Triaged
Depends on:
Blocks:
 
Reported: 2013-08-14 06:16 CEST by Olivier Thauvin
Modified: 2017-08-21 21:15 CEST (History)
2 users (show)

See Also:
Source RPM: bind-9.10.2.P4-1.mga5.src.rpm
CVE:
Status comment:


Attachments

Description Olivier Thauvin 2013-08-14 06:16:09 CEST
Description of problem:

Each time bind service is restarted the chroot is remounted. After some restart the output of "mount" command is unreadable.

The script should not mount again the chroot if it's already done.

"mount" extract:
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
sunrpc on /proc/fs/nfsd type nfsd (rw,relatime)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
/dev/mapper/vg--mercure-root on /var/lib/named/usr/lib64/bind type ext4 (ro,relatime,data=ordered)
/dev/mapper/vg--mercure-root on /var/lib/named/usr/lib64/bind type ext4 (ro,relatime,data=ordered)
/dev/mapper/vg--mercure-root on /usr/lib64/bind type ext4 (rw,relatime,data=ordered)
/dev/mapper/vg--mercure-root on /var/lib/named/usr/lib64/bind type ext4 (ro,relatime,data=ordered)
/dev/mapper/vg--mercure-root on /usr/lib64/bind type ext4 (rw,relatime,data=ordered)
/dev/mapper/vg--mercure-root on /var/lib/named/usr/lib64/bind type ext4 (rw,relatime,data=ordered)
/dev/mapper/vg--mercure-root on /usr/lib64/bind type ext4 (rw,relatime,data=ordered)

[root@hermes ~]# mount | grep bind | wc -l
255


Reproducible: 

Steps to Reproduce:
Comment 1 Olivier Thauvin 2013-08-14 06:30:20 CEST
It seems this happend when named failed to start (because a typo in named.conf for example).
Manuel Hiebel 2013-08-15 00:00:35 CEST

Assignee: bugsquad => guillomovitch
Keywords: (none) => Triaged

Comment 2 David Walser 2013-08-15 04:09:14 CEST
Yes, when named starts successfully, it shuts down successfully, which umounts all the bind mounts, and this problem doesn't occur.  The script that sets up the chroot and bind mounts is very problematic, and comes from Fedora.  Patches are welcome.

CC: (none) => luigiwalser

Comment 3 Guillaume Rousse 2013-12-31 17:25:02 CET
I guess adding this condition into each of three loops of the mount_chroot_conf() function should fix the issue:

# skip if target exists and is already a mount point
[ -e $target ] && mountpoint $target >/dev/null && continue

Resolution: (none) => FIXED
Status: NEW => RESOLVED

Guillaume Rousse 2013-12-31 17:25:13 CET

Status: RESOLVED => REOPENED
Resolution: FIXED => (none)

Comment 4 Guillaume Rousse 2013-12-31 17:25:42 CET
Oops, wrong change.

Status: REOPENED => ASSIGNED

Comment 5 David Walser 2014-06-10 22:22:17 CEST
I just saw this in the RHEL7 release notes, which may be relevant:
bind component, BZ#1004300
    Previously, named-chroot.service was setting up the chroot environment for the named daemon by mounting necessary files and directories to the /var/named/chroot/ path before starting the daemon. However, if the start up of the daemon failed, the mounts remained mounted. As a consequence, the chroot environment was corrupted. This also affected named-sdb-chroot.service, which was using the same chroot path. With this update, named-chroot.service and named-sdb-chroot.service have been modified and the chroot set up code has been separated into two new systemd services, named-chroot-setup.service and named-sdb-chroot-setup.service. In addition, the named-sdb daemon now uses its own chroot path, /var/named/chroot_sdb/. Also, named-sdb daemon has been removed from the bind-chroot package and is now included in its own bind-sdb-chroot subpackage. Users who use named-sdb in the chroot environment are advised to install the bind-sdb-chroot package.
claire robinson 2015-02-23 14:23:11 CET

Version: 3 => 4

Comment 6 Stefan Puch 2015-02-23 19:01:19 CET
(In reply to David Walser from bug 15326 comment #17)

I'm not sure if this is the right ticket to report about but if advisted I will do so...

>Your zone files are stored in /var/named, which is then bind mounted to /var/lib
> /named/var/named when the service is run.

You are right, the problem seems to be a messed up directory /var/lib/named/var/named because if there are directories left over from history the whole directory /var/named is skipped instead of being mounted to chroot.
If the directory /var/lib/named/var/named before the start-up bind all zone files stored in /var/named will be mounted correctly, sorry for that.

>If you have errors in your named.conf (which would be your fault, not the >package's), the service will fail,...
That's true but who can assume, that the user configs which are located in directory /etc/named and correctly referenced in named.conf are not available because the chroot script /usr/sbin/setup-named-chroot.sh simply ignores them?

For me it looks like a bug in that file because line 5 list '/etc/named' for the variable FILE_RO_SOURCES. If it would be '/etc/named/*' (I added that for testing now) the config files are handled correctly (what means that they are mounted to chroot)

CC: (none) => s.puch

Comment 7 David Walser 2015-02-23 19:06:22 CET
Improvements to the script are welcome.

Long-term what I'd maybe like to see if to have that awful script dropped completely and to have this converted to maybe use systemd-nspawn to do the chrooting.
Comment 8 Stefan Puch 2015-07-14 09:14:16 CEST
By applying security update MGASA-2015-0272 I run again into the problem that nameservice was dead after restart.

The update reverted my temporary fix mentioned in commet 6.
Would it be possible to change variable FILE_RO_SOURCES in chroot script (/usr/sbin/setup-named-chroot.sh) from '/etc/named' to '/etc/named/*' so that user configs are mounted correctly to chroot? I wonder if I'm the only one who ran into that problem? Does no one use config files in /etc/named/?
Comment 9 Samuel Verschelde 2015-09-21 13:21:56 CEST
Mageia 4 changed to end-of-life (EOL) status on 2015-09-19. It is is no longer 
maintained, which means that it will not receive any further security or bug 
fix updates.

Package Maintainer: If you wish for this bug to remain open because you plan to 
fix it in a currently maintained version, simply change the 'version' to a later 
Mageia version.

Bug Reporter: Thank you for reporting this issue and we are sorry that we weren't 
able to fix it before Mageia 4's end of life. If you are able to reproduce it 
against a later version of Mageia, you are encouraged to click on "Version" and 
change it against that version of Mageia. If it's valid in several versions, 
select the highest and add MGAxTOO in whiteboard for each other valid release.
Example: it's valid in cauldron and Mageia 5, set to cauldron and add MGA5TOO.

Although we aim to fix as many bugs as possible during every release's lifetime, 
sometimes those efforts are overtaken by events. Often a more recent Mageia 
release includes newer upstream software that fixes bugs or makes them obsolete.

If you would like to help fixing bugs in the future, don't hesitate to join the
packager team via our mentoring program [1] or join the teams that fit you 
most [2].

[1] https://wiki.mageia.org/en/Becoming_a_Mageia_Packager
[2] http://www.mageia.org/contribute/
Comment 10 Stefan Puch 2015-09-21 15:36:13 CEST
As advised in comment 9 I changed version to 5 as the problem is still valid in MGA 5. I changed plattform to i586 because I verified it on i586 system, but x86_64 should be affected, too (plattform independent bug).

Comment 8 is still fixes the problem for me. I hope it will be possible to add the missing "/" to the chroot-script soon, because every security update the problem rises again...

Source RPM: bind-9.9.3.P2-1.mga3.src.rpm => bind-9.10.2.P4-1.mga5.src.rpm
Hardware: x86_64 => i586
Version: 4 => 5

David Walser 2015-09-21 15:39:35 CEST

Whiteboard: (none) => MGA5TOO
Version: 5 => Cauldron

Rémi Verschelde 2015-09-21 15:56:59 CEST

Hardware: i586 => All

Comment 11 Guillaume Rousse 2016-08-21 15:14:47 CEST
Changing '/etc/named' to '/etc/named/*' would change the current script behavior from 'bind-mount one directory, unless it already exists and is not empty' to 'bind-mount multiple files, skipping those already existing'. It would indeed workaround the issue when /var/lib/named/etc/named is not empty, but that is not supposed to be the case, so I'm a bit reluctant for this change. I'll however follow the RHEL change of splitting services, to avoid corrupt chroot issue when the service fails to start.

BTW, you can freely redefine all variables in /etc/sysconfig/named file, it won't be affected by updates.
Comment 12 Stefan Puch 2016-08-21 16:50:15 CEST
It would be enough to change '/etc/named' to '/etc/named/' (on '/' at the end). Would that change the script behavior as well?

>BTW, you can freely redefine all variables in /etc/sysconfig/named file, it >won't be affected by updates.
Thanks for that hint, I will give that a try.
Comment 13 Guillaume Rousse 2017-08-21 21:15:40 CEST
The whole point of not bind-mounting a directory if its target already exists and is not empty is supposed (I guess) to be a safety when people intentionally populate the chroot manually. Indeed, it also makes the script less robust against left over from previous mount/unmount sequence. Changing this trade-of would require to change the script behaviour, and I'd rather change the test explicitly than use syntax tricks to achieve this. For instance, just check if the target is already a mount point, as initially suggested in an earlier comment.

However, I'm not convinced about the desirability of such change. My current understanding is that the main issue (messed up chroot state issue due to unmount errors) has been largely reduced by the service splitting. And the current behaviour, while not perfect, and not documented, is at least known and expected. A change will eventually cause problems for people relying on it. Hence I prefer to keep it.

Here are various local workarounds that should survive updates:
- override DIR_RO_SOURCES and FILE_RO_SOURCES in /etc/sysconfig/named
- override named-chroot-setup.service to call another chroot creation script, for instance the original one with the safety check disabled

Resolution: (none) => WONTFIX
Status: ASSIGNED => RESOLVED


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