Created attachment 1015631 [details]
patch to fix network-functions

What happened before?

Originally, I encountered this bug in CENTOS 7.1 and filed it there: http://bugs.centos.org/view.php?id=8490

The centos guys have sent me over here to report it, because they cannot address it directly.

I HAVE NOT TESTED THIS ISSUE IN RHEL!



Description of problem:

Starting with CentOS 7.1 change_resolv_conf() (in /etc/sysconfig/network-scripts/network-functions) deletes all rows except options from /etc/resolv.conf, when resolv.conf options are configured (RES_OPTIONS=...)


Version-Release number of selected component (if applicable):

$ rpm -qf /etc/sysconfig/network-scripts/network-functions
initscripts-9.49.24-1.el7.x86_64 



How reproducible:

I use CentOS 7 in a vagrant image that I build with packer from the CentOS minimal isos. But this should be reproducible in other setups, too.

To workaround a DNS bug in virtualbox I have a resolve option configured:

$ cat /etc/sysconfig/network
# Created by anaconda
RES_OPTIONS=single-request-reopen


One of the network interfaces uses DHCP. Thus, dhclient is triggered upon boot/reboot. This is printed in /var/log/messages:

Apr 17 07:47:49 localhost dhclient[789]: DHCPDISCOVER on enp0s3 to 255.255.255.255 port 67 interval 3 (xid=0x52fcbf18)
Apr 17 07:47:49 localhost dhclient[789]: DHCPREQUEST on enp0s3 to 255.255.255.255 port 67 (xid=0x52fcbf18)
Apr 17 07:47:49 localhost dhclient[789]: DHCPOFFER from 10.0.2.2
Apr 17 07:47:49 localhost dhclient[789]: DHCPACK from 10.0.2.2 (xid=0x52fcbf18)
Apr 17 07:47:49 localhost kernel: floppy0: no floppy controllers found
Apr 17 07:47:51 localhost NET[834]: /usr/sbin/dhclient-script : updated /etc/resolv.conf
Apr 17 07:47:51 localhost dhclient[789]: bound to 10.0.2.15 -- renewal in 43148 seconds.
Apr 17 07:47:51 localhost network: Determining IP information for enp0s3... done.
Apr 17 07:47:51 localhost network: [ OK ]


After "updated /etc/resolv.conf" has happened, the resolv.conf contains only options.

Actual results:

$ cat /etc/resolv.conf 
options single-request-reopen

Expected result:

$ cat /etc/resolv.conf 
; generated by /usr/sbin/dhclient-script
search .....
options single-request-reopen
nameserver 10.0.2.3



Additional info:

Digging into /usr/sbin/dhclient-script and /etc/sysconfig/network-scripts/network-functions, we could see that the DHCP response was correct. dhclient-script puts the proposed resolv.conf into a tempfile and calls change_resolv_conf() with the tmpfile as $1.

I step through change_resolv_conf() to explain the problem.

At first the options from the _existing_ /etc/resolv.conf are saved. (This is why this bug may only appear after a reboot and not on the first boot).

    s=$(/bin/grep '^[\ \ ]*option' /etc/resolv.conf 2>/dev/null);
    if [ "x$s" != "x" ]; then
       s="$s"$'\n';
    fi;

Options are grepped into $s. If there are options a newline is appended to $s. -> This is the cause of the bug.

In my case the function receives only one parameter (the tmpfile), so I did not examine the if block. We step into the else block:

    elif [ $# -eq 1 ]; then
       if [ "x$s" != "x" ]; then
          s="$s"$(/bin/grep -vF "$s" $1);
       else
          s=$(cat $1);
       fi;
    fi;

If options are not empty, the result are the options ($s) followed by the tmp resolv.conf ($1) that is cleared from exactly the existing options.

This grep returns nothing in CentOS 7.1 (grep 2.20) and the expected resolv.conf w/o options in CentOS 7.0 (grep 2.16).

I assume that grep 2.19 has introduced this new behaviour, that was actually a bug fix: 
http://savannah.gnu.org/forum/forum.php?forum_id=7988 [^]

" grep no longer mishandles an empty pattern at the end of a pattern list. [bug introduced in grep-2.5]"

This is exactly what has happened here. The $s contains one or more option lines followed by a redundant newline. The documentation of grep -F says:

" -F, --fixed-strings PATTERN is a set of newline-separated fixed strings"

The appended newline causes an empty string to be interpreted as a fixed string pattern. The empty string matches every line and -v removes all of them from the output.


I have attached a conservative patch for network-functions that avoids the bug in the else-block (change_resolv_conf /tmp/foo). A better fix would be to not append the \n in the first place. But as I don't know when change_resolv_conf is called with more parameters (if-block), I could not check if that would brake anything else.