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

Bug #932275 reported by Matthew L. Dailey on 2012-02-14
28
This bug affects 4 people
Affects Status Importance Assigned to Milestone
ifupdown (Ubuntu)
High
Stéphane Graber
netcfg (Ubuntu)
High
Stéphane Graber
resolvconf (Ubuntu)
High
Unassigned

Bug Description

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.

The "better" patch.

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.]

tags: added: patch
Launchpad Janitor (janitor) wrote :

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

Changed in netcfg (Ubuntu):
status: New → Confirmed
Thomas Hood (jdthood) wrote :

Could this also be the cause of #214492?

Thomas Hood (jdthood) wrote :

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

Changed in netcfg (Ubuntu):
status: Confirmed → Triaged
assignee: nobody → Stéphane Graber (stgraber)
Steve Langasek (vorlon) on 2012-02-23
Changed in netcfg (Ubuntu):
importance: Undecided → High
Stéphane Graber (stgraber) wrote :

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) wrote :

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

Changed in netcfg (Ubuntu):
status: Triaged → Fix Released
Stéphane Graber (stgraber) wrote :

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) wrote :

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.

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) wrote :

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.

Changed in resolvconf (Ubuntu):
status: New → Triaged
importance: Undecided → High
Changed in ifupdown (Ubuntu):
status: New → Triaged
importance: Undecided → High
Launchpad Janitor (janitor) wrote :

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

Changed in resolvconf (Ubuntu):
status: Triaged → Fix Released
Thomas Hood (jdthood) wrote :

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

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) wrote :

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 :-)

Changed in ifupdown (Ubuntu):
assignee: nobody → Stéphane Graber (stgraber)
Changed in ifupdown (Ubuntu):
status: Triaged → In Progress
Changed in ifupdown (Ubuntu):
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

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

Changed in ifupdown (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers