Bug 177595

Summary: init.d/named script performs flawed grep of /proc/mounts
Product: [Fedora] Fedora Reporter: JW <ohtmvyyn>
Component: bindAssignee: Martin Stransky <stransky>
Status: CLOSED CURRENTRELEASE QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: 5Keywords: Reopened
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: 9.3.3-0.1.rc2.fc5 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-12-06 08:49:03 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description JW 2006-01-12 01:51:31 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; MSIE 6.0; Windows; U; AIIEEEE!; Win98; Windows 98; en-US; Gecko masquerading as IE; should it matter?; rv:1.8b) Gecko/20050217

Description of problem:
There is code in /etc/rc.d/init.d/named that attempts to bind-mount /proc if it isn't already mounted under chrooted (sic) hierarchy.
It does this by grep'ing /proc/mounts for "/proc ${ROOTDIR}/proc".

This is wrong because it presumes that the real path of ${ROOTDIR}/proc is the same as the ${ROOTDIR}/proc.


Version-Release number of selected component (if applicable):
bind-9.3.1-14_FC4

How reproducible:
Always

Steps to Reproduce:
1.mv /var/named/chroot /X
2.ln -s /X /var/named/chroot
3./etc/rc.d/init.d/named start
4./etc/rc.d/init.d/named restart
5./etc/rc.d/init.d/named restart
6.cat /proc/mounts
 

Actual Results:  ....
/proc /X/proc proc rw,nodiratime 0 0
/proc /X/proc proc rw,nodiratime 0 0
/proc /X/proc proc rw,nodiratime 0 0


Expected Results:  ....
/proc /X/proc proc rw,nodiratime 0 0 #just once


Additional info:

There is a lot of horrible grep'ing in RedHat/Fedora scripts.
This is just another example amongst many.

It would be better to a use more robust and reliable way to determine whether a node is mounted, especially where aliasing can occur because of symlinks.

Possibilities that come to mind:
1. df ${ROOTDIR}/proc >/dev/null; use $?
2. somehow invoke a realpath(3) translation of ${ROOTDIR}/proc, then grep it.
3. mount -o remount,rw ${ROOTDIR}/proc 2>/dev/null || mount /proc ${ROOTDIR}/proc

I think 3) is the one that I will be patching for.

Comment 1 JW 2006-01-12 01:56:12 UTC
Correction (omitted the --bind):

3. mount -o remount,rw ${ROOTDIR}/proc 2>/dev/null || mount --bind /proc
${ROOTDIR}/proc



Comment 2 Jason Vas Dias 2006-03-07 16:21:35 UTC
This bug is now fixed with bind-9.3.2-6 in Rawhide, and will be fixed in 
bind-9.3.1-16.FC4, to be released to FC-4 updates/testing today.

Comment 3 Fedora Update System 2006-03-08 04:43:11 UTC
From User-Agent: XML-RPC

bind-9.3.1-16_FC4 has been pushed for FC4, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.

Comment 4 Fedora Update System 2006-03-21 17:55:55 UTC
bind-9.3.2-10.FC5 has been pushed for FC5, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.

Comment 5 Fedora Update System 2006-03-21 17:56:11 UTC
bind-9.3.1-18.FC4 has been pushed for FC4, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.

Comment 6 Bill Nottingham 2006-09-22 02:11:16 UTC
Closing bugs in MODIFIED state from prior Fedora releases. If this bug persists
in a current Fedora release (such as Fedora Core 5 or later), please reopen and
set the version appropriately.

Comment 7 Martin Stransky 2006-10-26 11:17:08 UTC
Are you sure that it isn't fixed in FC5? I've just checked it and it works fine...

Comment 8 JW 2006-10-26 11:48:51 UTC
You have checked with symlinked chroot hierarchy?


Comment 9 Martin Stransky 2006-10-26 14:06:44 UTC
I've checked your steps to reproduce, package bind-9.3.3-0.1.rc2.fc5 (the latest
FC5 update)...


Comment 10 JW 2006-10-26 14:13:59 UTC
Must be fixed then.