[Bug 1825194] [NEW] [SRU] resolvconf is racy, which leads to broken resolv.conf in parallel calls

[Launchpad Bug Tracker]

You have been subscribed to a public bug by Alfonso Sanchez-Beato (alfonsosanchezbeato):

[Impact]

The bug can lead to non-working DNS. This is a critical bug that needs
to be fixed in the stable release.

The patch fixes the bug by using a file lock via the flock command.

[Test case]

This script should eventually stop with the current version, thing that
should not happen after applying the patch:

while true; do
    printf "\n" | sudo resolvconf -a NetworkManager
    printf "nameserver 8.8.8.8\n" | sudo resolvconf -a networkd
    wait
    printf "nameserver 8.8.8.8\n" |
        sudo resolvconf -a NetworkManager &
    printf "\n" | sudo resolvconf -a networkd
    wait
    ping -c 1 www.google.com || break
done

[Regression Potential]

The patch is small and what it does is straightforward. It has also been
thoroughly tested. However, the effect if something is wrong would be
not being able to resolve DNS names, which is disastrous, so it needs to
be very well tested for the SRU.

[Other Info]

It has been found that simultaneous calls to resolvconf can lead to
inconsistent content in resolv.conf. For instance, no nameservers while
NetworkManager has one in its record (see LP: #1824395):

$ cat /run/resolvconf/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN

$ cat /run/resolvconf/interface/NetworkManager
nameserver 192.168.1.6
nameserver 192.168.1.2

This can happen easily when calling "netplan apply", which can re-start
both networkd and NM. resolvconf is called at that point by the
"systemd-networkd-resolvconf-update.service" service, and also directly
by NetworkManager, which leads to the situation described above. This is
not surprising as there is nothing preventing different instances of
resolvconf to access the same files. This sort of situation can be
reproduced by running in a loop commands like:

$ printf "\n" | sudo resolvconf -a NetworkManager & printf "\n" | sudo resolvconf -a networkd
$ printf "nameserver 80.58.61.250\n" | sudo resolvconf -a NetworkManager & printf "\n" | sudo resolvconf -a networkd

Eventually, this leads to a resolv.conf that is not consistent with the
last run command.

** Affects: resolvconf (Ubuntu)
     Importance: Critical
         Status: Fix Released

** Affects: resolvconf (Ubuntu Xenial)
     Importance: Critical
         Status: In Progress


** Tags: disco patch rls-ee-incoming
-- 
[SRU] resolvconf is racy, which leads to broken resolv.conf in parallel calls
https://bugs.launchpad.net/bugs/1825194
You received this bug notification because you are a member of Ubuntu Sponsors Team, which is subscribed to the bug report.