After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 681103 - Network Manager Clobbers /etc/resolv.conf and default route after plugin of new device (e.g. USB)
Network Manager Clobbers /etc/resolv.conf and default route after plugin of n...
Status: RESOLVED OBSOLETE
Product: NetworkManager
Classification: Platform
Component: general
0.9.x
Other Linux
: Normal normal
: ---
Assigned To: Pavel Simerda
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2012-08-03 01:59 UTC by Chris Hiestand
Modified: 2013-05-06 13:24 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Chris Hiestand 2012-08-03 01:59:29 UTC
This bug could be used as a physical DoS attack on a machine running NetworkManager.

My configuration:
Tested in Debian Wheezy with version 0.9.5.95-1

I actually do not want to use Network Manager at all. These systems are configured with configuration management and do not need dynamic network settings. However, in Debian gnome depends upon installation of NetworkManager (network-manager), so I must install NetworkManager to install gnome.

chiestand@sagan:/$ cat /etc/NetworkManager/NetworkManager.conf 
[main]
plugins=ifupdown,keyfile

[ifupdown]
managed=false

In /etc/network/interfaces I only have 2 interfaces configured:
lo
eth0

So network manager manages any non-defined interfaces, such as eth1 (onboard) or a USB network device.


What Happened, Part One:
A user reported that when she plugged her cell phone into her computer to charge it, she lost all network access. I verified this. The phone (HTC Hera 110 running Windows Mobile 6) acts as a network device much like a USB ethernet dongle. Upon plug-in, Network Manager runs and replaces /etc/resolv.conf with the blank file "# Generated by NetworkManager" because the phone is not actually configured to act as a gateway and Network Manager decides to use null information. However, I'm not sure exactly what the phone is communicating to the computer.


What I Expected Would Happen, Part One:
/etc/resolv.conf would remain unchanged


What Happened, Part Two:
Further testing with a USB ethernet cable that is connected to our network showed that Network Manager changes the default route.

Here is the normal route:
chiestand@sagan:/tmp$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.0.1    0.0.0.0         UG    0      0        0 eth0
10.0.0.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0

Here is the route after plugging in a USB ethernet device:
0.0.0.0         10.0.0.1    0.0.0.0         UG    0      0        0 eth3
10.0.0.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.0.0.0    0.0.0.0         255.255.255.0   U     0      0        0 eth3

Notice the default route has been switch to use eth3 instead of eth0. This is bad because the system hangs after eth3 is unplugged, due to NFS and LDAP failures.


What I Expected Would Happen, Part Two:
Either:
Network Manager would not modify the route
-or-
Network Manager would restore the route to the original route after the USB ethernet cable was unplugged


Recommend Solution(s):
First, Network Manager should never replace /etc/resolv.conf with an empty file. If it has no resolver data, it should not erase what is current.

Second, if Network Manager truly is required for gnome, but it is not required to be running, there should be a way to disable it. On Debian, there would be a disable variable in /etc/default/network-manager that you could set to avoid running NetworkManager.

If NM is required for gnome, and must be running, then there should be a way to disable it from managing ANY network devices. Currently you can only disable NM from managing devices configured in /etc/network/interfaces.

If NM is not required for gnome, I will file a Debian bug such that gnome-core should not depend on network-manager-gnome (which depends on network-manager).


How to reproduce:
1. Start Network Manager.
2. Plug in an additional ethernet device that has not already been configured (such as USB ethernet dongle).
3. /etc/resolv.conf and route is clobbered

Thanks.
Comment 1 Chris Hiestand 2012-08-06 18:42:20 UTC
This bug has also been reported here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598911
Comment 2 Pavel Simerda 2012-08-16 22:05:26 UTC
> This bug could be used as a physical DoS attack on a machine running
> NetworkManager.

There are lots of other ways to physically DoS any machine...

> My configuration:
> Tested in Debian Wheezy with version 0.9.5.95-1
> 
> I actually do not want to use Network Manager at all.

Nobody should be forced to use NetworkManager. Forcing someone to use it should
be considered a bug.

> These systems are
> configured with configuration management and do not need dynamic network
> settings. However, in Debian gnome depends upon installation of NetworkManager
> (network-manager), so I must install NetworkManager to install gnome.

Even though in my opinion Gnome packages should not depend on NetworkManager, it
is not such a big deal. You don't have to use NM.

Just disable it with your init system and file/comment bugreports if this doesn't work for you. If NM spuriously restarts for you, please check the
init configuration *and* the configuration of dbus (especialy dbus activation).

> chiestand@sagan:/$ cat /etc/NetworkManager/NetworkManager.conf 
> [main]
> plugins=ifupdown,keyfile
> 
> [ifupdown]
> managed=false

I didn't even know we have this one.

> In /etc/network/interfaces I only have 2 interfaces configured:
> lo
> eth0
> 
> So network manager manages any non-defined interfaces, such as eth1 (onboard)
> or a USB network device.

Please see bug 673537.

> What Happened, Part One:
> A user reported that when she plugged her cell phone into her computer to
> charge it, she lost all network access. I verified this. The phone (HTC Hera
> 110 running Windows Mobile 6) acts as a network device much like a USB ethernet
> dongle. Upon plug-in, Network Manager runs and replaces /etc/resolv.conf with
> the blank file "# Generated by NetworkManager" because the phone is not
> actually configured to act as a gateway and Network Manager decides to use null
> information.

This should most probably be handled more gracefully. But NM normally assumes
that no connection warrants empty resolv.conf. But probably the smooth assumption of connections and smooth restart features of NM are also
affected by this behavior.

> However, I'm not sure exactly what the phone is communicating to
> the computer.

It's probably not so important. In this case I belive NM reacts just to the fact of newly managing an interface.

> What I Expected Would Happen, Part One:
> /etc/resolv.conf would remain unchanged

That might be a better behaviour. But it has consequences.

> What Happened, Part Two:
> Further testing with a USB ethernet cable that is connected to our network
> showed that Network Manager changes the default route.

Interesting.

> Here is the normal route:
> chiestand@sagan:/tmp$ route -n
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
> 0.0.0.0         10.0.0.1    0.0.0.0         UG    0      0        0 eth0
> 10.0.0.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
> 
> Here is the route after plugging in a USB ethernet device:
> 0.0.0.0         10.0.0.1    0.0.0.0         UG    0      0        0 eth3
> 10.0.0.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
> 10.0.0.0    0.0.0.0         255.255.255.0   U     0      0        0 eth3

Please use 'ip route' next time for better output. But the 'metric' is there
and it's the same for eth0 and eth3. This can break thing, too.

> Notice the default route has been switch to use eth3 instead of eth0. This is
> bad because the system hangs after eth3 is unplugged, due to NFS and LDAP
> failures.

These services should be fixed then. System should never hang up just because of network configuration changes. But that's another case.

> What I Expected Would Happen, Part Two:
> Either:
> Network Manager would not modify the route

This is a policy decision. But USB ethernet should probably *not* be favoured
over internal NIC.

> -or-
> Network Manager would restore the route to the original route after the USB
> ethernet cable was unplugged

It can't reasonably do it before as NM can't predict the user's intention to
remove the USB ethernet cable. To fix this, kernel cooperation would be needed,
so it can be considered a much harder issue.

> Recommend Solution(s):
> First, Network Manager should never replace /etc/resolv.conf with an empty
> file.

Sounds reasonable but can have consequences.

> If it has no resolver data, it should not erase what is current.

I'm afraid we need to remove network configuration in many cases. But this
requires further research.

> Second, if Network Manager truly is required for gnome,

NM should not be requred for running gnome and IMO not even for installing. But
others may have different opinions.

> but it is not required
> to be running, there should be a way to disable it.

NM is started by the init system. NM should not be started by any other means except for debugging. The init system should be able to cope with enabling/disabling services. If NM is automatically started by other means,
it is a bug and should be reported accordingly.

> If NM is required for gnome, and must be running, then there should be a way to
> disable it from managing ANY network devices.

When NM is running, it should be configurable *not* to auto-manage new devices. It currently supports MAC blacklisting but it should also support whitelisting
as described in bug 673537 and administratively started device management as
described in bug 680909.

> If NM is not required for gnome, I will file a Debian bug such that gnome-core
> should not depend on network-manager-gnome (which depends on network-manager).

Please do and if it *is* required, please file a Gnome bug to make it at least
running optionally. Also, this greatly depends on what version of Gnome are you running.

> How to reproduce:
> 1. Start Network Manager.
> 2. Plug in an additional ethernet device that has not already been configured
> (such as USB ethernet dongle).
> 3. /etc/resolv.conf and route is clobbered
> 
> Thanks.

Thank *you*! You have just described a very simple use case that triggers so many problems and missing features of NetworkManager.

This bug report will have to be triaged and divided into separate bug reports for separate problems. I tried to link to all bug reports that have already
been filed. Assigning to myself for the purpose of triaging (not for the purpose of fixing all these bugs).
Comment 3 Chris Hiestand 2012-08-24 07:13:04 UTC
> > This bug could be used as a physical DoS attack on a machine running
> > NetworkManager.
> 
> There are lots of other ways to physically DoS any machine…

Good point. The main difference here is that it would probably be
done unintentionally :-)



> > Notice the default route has been switch to use eth3 instead of eth0. This is
> > bad because the system hangs after eth3 is unplugged, due to NFS and LDAP
> > failures.
> 
> These services should be fixed then. System should never hang up just because
> of network configuration changes. But that's another case.

Perhaps a bad choice of word, I didn't mean indefinite hang, but rather very
long delay (and likely failure). This is largely unavoidable when using nfs-mounted
home directories with ldap and a route failure occurs.


> > What I Expected Would Happen, Part Two:
> > Either:
> > Network Manager would not modify the route
> > 
> This is a policy decision. But USB ethernet should probably *not* be favoured
> over internal NIC.

Strong agreement on the policy decision. Another use case to consider is when
a user plugs in and unplugs a second (non-USB) ethernet NIC



> > Recommend Solution(s):
> > First, Network Manager should never replace /etc/resolv.conf with an empty
> > file.
> 
> Sounds reasonable but can have consequences.

I can't imagine a consequence worse than an empty resolv.conf. The worst
that could happen is that the NS used is not reachable - but the effect of
that is exactly the same as an empty resolv.conf.  So you might as well
leave resolv.conf unempty because it is better than nothing.

An alternative is to work out a way to more intelligently set resolv.conf so
a guessing game is not required. And even in this scenario, resolv.conf is
never empty.



> > If it has no resolver data, it should not erase what is current.
> 
> I'm afraid we need to remove network configuration in many cases. But this
> requires further research.

That seems appropriate.



> > Second, if Network Manager truly is required for gnome,
> 
> NM should not be requred for running gnome and IMO not even for installing. But
> others may have different opinions.

> > but it is not required
> > to be running, there should be a way to disable it.

> NM is started by the init system. NM should not be started by any other means
> except for debugging. The init system should be able to cope with
> enabling/disabling services. If NM is automatically started by other means,
> it is a bug and should be reported accordingly.

Debian does not currently support a way to disable NM in init, e.g. by having
a DISABLE shell variable. I requested this in a Debian bug report.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685742


> > If NM is not required for gnome, I will file a Debian bug such that gnome-core
> > should not depend on network-manager-gnome (which depends on network-manager).

> Please do and if it *is* required, please file a Gnome bug to make it at least
> running optionally. Also, this greatly depends on what version of Gnome are you
> running.


I sent an email to the Debian Gnome package maintainers enquiring on this topic.


Thanks a lot for the thorough reply. I appreciate it greatly.
Comment 4 Pavel Simerda 2012-09-05 07:30:35 UTC
(In reply to comment #3)
> > > This bug could be used as a physical DoS attack on a machine running
> > > NetworkManager.
> > 
> > There are lots of other ways to physically DoS any machine…
> 
> Good point. The main difference here is that it would probably be
> done unintentionally :-)
> 
> 
> 
> > > Notice the default route has been switch to use eth3 instead of eth0. This is
> > > bad because the system hangs after eth3 is unplugged, due to NFS and LDAP
> > > failures.
> > 
> > These services should be fixed then. System should never hang up just because
> > of network configuration changes. But that's another case.
> 
> Perhaps a bad choice of word, I didn't mean indefinite hang, but rather very
> long delay (and likely failure). This is largely unavoidable when using
> nfs-mounted
> home directories with ldap and a route failure occurs.
> 
> 
> > > What I Expected Would Happen, Part Two:
> > > Either:
> > > Network Manager would not modify the route
> > > 
> > This is a policy decision. But USB ethernet should probably *not* be favoured
> > over internal NIC.
> 
> Strong agreement on the policy decision. Another use case to consider is when
> a user plugs in and unplugs a second (non-USB) ethernet NIC
> 
> 
> 
> > > Recommend Solution(s):
> > > First, Network Manager should never replace /etc/resolv.conf with an empty
> > > file.
> > 
> > Sounds reasonable but can have consequences.
> 
> I can't imagine a consequence worse than an empty resolv.conf. The worst
> that could happen is that the NS used is not reachable - but the effect of
> that is exactly the same as an empty resolv.conf.  So you might as well
> leave resolv.conf unempty because it is better than nothing.

Unfortunately not. Empty resolv.conf will lead to immediate errors, while
non-empty one can lead to timeouts which is a bad user experience. And this
also applies to reverse DNS.

This is too defensive and there's no point in keeping old DNS configuration
when you don't have a default gateway anyway.

> An alternative is to work out a way to more intelligently set resolv.conf so
> a guessing game is not required. And even in this scenario, resolv.conf is
> never empty.

What guessing game it is?

> > > If it has no resolver data, it should not erase what is current.
> > 
> > I'm afraid we need to remove network configuration in many cases. But this
> > requires further research.
> 
> That seems appropriate.
> 
> 
> 
> > > Second, if Network Manager truly is required for gnome,
> > 
> > NM should not be requred for running gnome and IMO not even for installing. But
> > others may have different opinions.
> 
> > > but it is not required
> > > to be running, there should be a way to disable it.
> 
> > NM is started by the init system. NM should not be started by any other means
> > except for debugging. The init system should be able to cope with
> > enabling/disabling services. If NM is automatically started by other means,
> > it is a bug and should be reported accordingly.
> 
> Debian does not currently support a way to disable NM in init, e.g. by having
> a DISABLE shell variable. I requested this in a Debian bug report.
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685742

chkconfig/update-rc.d as suggested in the debian bug won't work?

> > > If NM is not required for gnome, I will file a Debian bug such that gnome-core
> > > should not depend on network-manager-gnome (which depends on network-manager).
> 
> > Please do and if it *is* required, please file a Gnome bug to make it at least
> > running optionally. Also, this greatly depends on what version of Gnome are you
> > running.
> 
> 
> I sent an email to the Debian Gnome package maintainers enquiring on this
> topic.
> 
> 
> Thanks a lot for the thorough reply. I appreciate it greatly.

Thanks.
Comment 5 Pavel Simerda 2013-05-06 13:24:18 UTC
For explicit priority setting, please see:

https://bugzilla.gnome.org/show_bug.cgi?id=580018

NetworkManager master now supports turning off automatically generated connections, see bug 688857.

We don't want to put obsolete information to /etc/resolv.conf and we will most probably prefer using a local recursive nameserver in the future.

If there's anything else I've forgotten, a new bug report should be started to avoid confusion. Thanks.