Bogus or no nameserver information written to /etc/network/interfaces

[Matthew L. Dailey]

Doing a test install of precise with static networking, I noticed bogus (non-ASCII) data written on the dns-nameservers line in /etc/network/interfaces, which was then be carried over to resolv.conf by the resolvconf package. Other times, this line would simply not be in /etc/network/interfaces at all.

After looking at the code and doing some testing, the problem seems to be that at the end of static.c, the netcfg_write_resolvconf_options is called with the nameserver_array array, but this array is never actually populated. So, in the best-case scenario, it's pointing at zeros in memory and doesn't put anything in the interfaces file, but in other cases, spits out whatever happens to be in memory. :-) As near as I can tell, it looks like this happened somewhere between version 1.68 from debian and version 1.68ubuntu1.

The fix is to either pass the namserver array from the iface struct, or just pass the struct itself and deal with it in the netcfg_write_resolvconf_options function.

I'll attach two patches - a quick-and-dirty one and one that matches the way the netcfg_write_resolv function works.

I'd love to have someone who's more familiar with the code have a look and make sure that I'm not doing anything bad, and then if it's helpful, I'm happy to create a debdiff.

Thanks and let me know if you have any questions or if there's any more info I can provide.

[Matthew L. Dailey (matthew-l-dailey)]

The "better" patch.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "Quick-and-dirty patch" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Thomas Hood (jdthood)]

Could this also be the cause of #214492?

[Thomas Hood (jdthood)]

I have just reproduced this by installing the 23 February 2012 precise-server-amd64.iso in a VirtualBox virtual machine and selecting manual interface configuration. The dns-search option is written correctly but after "dns-nameservers" and a space come two garbage characters.
--
Thomas

[Stéphane Graber (stgraber)]

I confirmed the fix to be working doing manual static installs.

Now quickly running through the other tests and will upload if they all pass.

[Launchpad Janitor (janitor)]

This bug was fixed in the package netcfg - 1.68ubuntu12

---------------
netcfg (1.68ubuntu12) precise; urgency=low

  * Apply patch from Matthew L. Dailey to fix the dns- entries in
    /etc/network/interfaces. (LP: #932275)
 -- Stephane Graber <email address hidden> Thu, 23 Feb 2012 12:27:28 -0500

[Stéphane Graber (stgraber)]

Can one of you attach an example of the bogus value? it'd help to make sure resolvconf will be dealing with it properly on upgrade.

[Thomas Hood (jdthood)]

Stéphane: Very good point. All systems that have been installed with static network configuration using the faulty netcfg had, and probably still have, broken /e/n/i files. IIUC that includes all Oneiric systems.

Unfortunately I don't have an example of a corrupted file on hand. But if I understand the bug description correctly, the string following "dns-nameservers" could be anything.

Resolvconf should probably deal with this problem. I've opened a new bug report, #940260.

[Matthew L. Dailey (matthew-l-dailey)]

Hi Stéphane,

I'm attaching an example /e/n/i file. Due to the nature of this bug, it's actually writing out initialized memory space, so the results are random. In the majority of cases, since this is a newly-booted system, the memory being pointed to is probably zeros, so nothing will actually get written. In fact, in trying to replicate it this morning, I could only do it with my preseeded install, not with a vanilla one.

I hope this helps. Let me know if you have any other questions or need any other info.

[Steve Langasek (vorlon)]

So we probably want to have resolvconf check for 'dns-nameservers [0-9A-Fa-f.:]+' on upgrade when deciding if there's valid info, instead of just 'dns-nameservers'; and likewise we should have ifupdown do a one-time scrub on upgrade of any values it finds that don't match this regexp.

[Launchpad Janitor (janitor)]

This bug was fixed in the package resolvconf - 1.63ubuntu9

---------------
resolvconf (1.63ubuntu9) precise; urgency=low

  * debian/config: dns-nameservers lines are only valid if they take an ipv4
    or ipv6 value, and earlier bugs in netcfg may spit out lines with garbage
    values instead. If we find one of these on initial configuration, don't
    consider it an example of valid dynamically-provided DNS information.
    LP: #932275.
 -- Steve Langasek <email address hidden> Fri, 24 Feb 2012 13:01:08 -0800

[Thomas Hood (jdthood)]

In #940260 I wrote (in reverse order):
> 3. Perhaps the maintainer scripts should detect a flawed-netcfg-corrupted
> /e/n/i and either notify the admin or give her the opportunity
> (via debconf?) to repair the corrupted file.

Steve Langasek's change in 1.63ubuntu9 implements the most important aspect of this, namely, not to accept garbage as a valid IP address for the purpose of deciding whether or not to append the original file.

A fix-the-bogus-dns-nameservers-line wizard would be nice, but if we were going to do that we would simply write a wizard for configuring ifupdown for resolvconf. What would be the correct way to implement such a thing in Ubuntu?

> 2. Perhaps resolvconf should check the validity of each nameserver
> address string fed to it. Currently it doesn't do so, even though it
> does some "normalization" of address strings.

The normalized_stdin() function in /sbin/resolvconf should also be enhanced to filter out bogus nameserver addresses. Otherwise those addresses will end up in resolv.conf, which is not what we want. This is a non-negligible issue, I think.

> 1. We need to check ifupdown and resolvconf code, thinking about
> what will happen when they get fed such dns-nameservers lines.

I will do this sometime this week, even though it means reading ifupdown code, which may still be written (yikes) in Literate Programming. ;)

--
Thomas

[Steve Langasek (vorlon)]

On Mon, Feb 27, 2012 at 08:23:33PM -0000, Thomas Hood wrote:

> A fix-the-bogus-dns-nameservers-line wizard would be nice, but if we
> were going to do that we would simply write a wizard for configuring
> ifupdown for resolvconf. What would be the correct way to implement
> such a thing in Ubuntu?

My intent is that ifupdown itself will clean these up as a one-time upgrade
fix.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

[SeanBoran (sean-boran)]

FYI.
I tested a daily server build of Ubuntu 12.04 beta today. The (duplicate) issue 938520 I had noted on /etc/resolv.conf and /etc/network/interfaces is fixed :-)

[Launchpad Janitor (janitor)]

This bug was fixed in the package ifupdown - 0.7~beta2ubuntu7

---------------
ifupdown (0.7~beta2ubuntu7) precise; urgency=low

  [ Wookey ]
  * Use cross-compiler when cross-compiling (LP: #967227)
    Also merged upstream as:
    http://anonscm.debian.org/hg/collab-maint/ifupdown/rev/b21bc14d9109

  [ Stéphane Graber ]
  * Cherry pick commits from upstream to fix the broadcast address (LP: #924880)
    http://anonscm.debian.org/hg/collab-maint/ifupdown/rev/d31ffdb89dbb
    http://anonscm.debian.org/hg/collab-maint/ifupdown/rev/b996bb5866f5
    http://anonscm.debian.org/hg/collab-maint/ifupdown/rev/fbe3c242d6f8
    http://anonscm.debian.org/hg/collab-maint/ifupdown/rev/bdfd32ad6287
    http://anonscm.debian.org/hg/collab-maint/ifupdown/rev/d144dfdd7940

  * Detect bogus dns-nameservers line in /etc/network/interfaces and
    automatically comment them (LP: #932275)
 -- Stephane Graber <email address hidden> Thu, 29 Mar 2012 17:39:32 -0400