The previous implementation of the parser for /etc/network/interfaces had
quite a few drawbacks:
- it expected the lines to be terminated with "\n", even the last line
- it ignored line wraps with "\\" followed by "\n"
- it expected over-long lines to be shorter than 510 characters
- it ignored line wraps on over-long lines
- it treated spaces and tabs differently
- it did not make sure to really tokenize on word boundaries
- it treated the equivalent stanzas "auto" and "allow-auto" differently
- it ignored the fact that the "allow-*" stanzas can take multiple arguments
that need to be separated to be recognized NetworkManager's processing later
- it allowed "non-block" stanzas to appear before a block
This patch is a rewrite of the parser to fix the issues mentioned:
- it accepts the last line even if it is not terminated by "\n"
- it skips over-long lines, emits a warning and even takes into account
that over-long lines may be wrapped to next lines
- it un-wraps wrapped lines
- it uses spaces and tabs equivalently to tokenize the input
- it treats "allow-auto" as a synonym to "auto"
- it splits multi-argument "auto"/"allow-*" into multiple
single-argument stanzas of the same type
- it warns on data stanzas before the first block stanza
When NM quits, we don't want to unmanage a device that has
an active connection and can take that connection over again when
NM starts back up. This makes '/etc/init.d/NetworkManager restart'
work seamlessly. All other devices get unmanaged so their
connection (and any dependent VPN connections or wpa_supplicant
processes) get terminated. This bug caused active VPN connections
over wifi to be left running even when they didn't have IP
connectivity.
There were two bugs:
1) the NMDevice class implemented connection_match_config() for
all device subclasses, but only Ethernet devices can assume
connections at startup. Thus the quit-time check passed for
active wifi devices too, and they weren't properly cleaned up
2) The logic for figuring out which devices to clean up after when
quitting was somewhat flawed; we want to default to unmanaging
devices and then skip that step for ones that meet specific
criteria. Instead the code defaulted to leaving all devices active
at shutdown.
More info:
https://bugzilla.redhat.com/show_bug.cgi?id=585394http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1172
dbus-glib was not properly enforcing the 'access' permissions on
object properties exported using its API. There were 2 specific bugs:
1) dbus-glib did not enforce the introspection read/write property
permissions, so if the GObject property definition allowed write
access (which is sometimes desirable), D-Bus clients could modify
that value even if the introspection said it was read-only
2) dbus-glib was not filtering out GObject properties that were
not listed in the introspection XML. Thus, if the GObject defined
more properties than were listed in the introspection XML (which is
also often useful, and NM uses this quite a bit) those properties
would also be exposed to D-Bus clients.
To fix this completely, you need to:
1) get dbus-glib master when the patch is commited, OR grab the
patch from https://bugzilla.redhat.com/show_bug.cgi?id=585394 and
build a new dbus-glib
2) rebuild NetworkManager against the new dbus-glib
If a new device wasn't supported, it gets destroyed by the
NMDevice constructor() method. But in the constructor paths
the DHCP manager isn't created yet, and so we attempt to unref
a non-existent DHCP manager. Usually just a harmless warning,
but apparently a crash sometimes.
DHCPv6 doesn't really use broadcast; instead clients use reserved
multicast addresses to talk to the server. ff02::1:2 (link scope)
and ff05::1:3 (site scope) are used. This means the routing table
has to have a route that can handle outgoing traffic to these
addresses, which is ff00::/8. The kernel sometimes adds one for us,
so we need to (a) make sure we don't tear that route down, and
(b) that if it's not there before we start DHCPv6, that we add it.
Otherwise dhclient complains about not being able to send outgoing
traffic from it's send_packet6() function with "no route to host".
It will then use an expired lease, which causes NM to assign that
leases IP address to the interface, whcih causes the kernel to
assign the required ff00::/8 route, and then dhclient performs a
renew (since the expired lease has expired of course) and then
everything works out in the end. But the latency sucks.
So make DHCPv6 faster by ensuring that dhclient has the routes
it needs before we start the DHCP session.
If it's not running or we can't spawn it (it's not supposed to be
autospawned anyway) we should just ignore the error and poke clients
that we've tried and failed to get user settings instead of warning
with an annoying message.
Many clients using libnm-glib (often command-line ones like nm-tool
or nmcli) aren't long-lived enough for NM to get their UID from
the bus daemon and validate their permissions via PolicyKit. So
when the NMClient object is created, get the permissions synchronously
(with a very low timeout to prevent unecessary blocking) to ensure
that the client is still on the bus when NM asks for it's credentials.
Avoids a ton of messages like:
NetworkManager[10274]: <warn> error requesting auth for org.freedesktop.NetworkManager.enable-disable-wwan: (6) Remote Exception invoking org.freedesktop.PolicyKit1.Authority.CheckAuthorization() on /org/freedesktop/PolicyKit1/Authority at name org.freedesktop.PolicyKit1: org.freedesktop.DBus.Error.NameHasNoOwner: Remote Exception invoking org.freedesktop.DBus.GetConnectionUnixUser() on / at name org.freedesktop.DBus: org.freedesktop.DBus.Error.NameHasNoOwner: Could not get UID of name ':1.95': no such name
The autoactivation code wasn't excluding subchannel-locked connections
when matching for devices that don't have subchannels. This only
produced a warning message though as the connection activation would
be failed by the check_connection_compatible hook.
If your hostname is 'foo.bar.baz' and your DNS server doesn't
actually reply to queries for 'foo.bar.baz' you can't just 'ping foo'
currently. While that may be somewhat of a misconfigured setup,
since we're already adding the domain part of the hostname to
/etc/resolv.conf we might as well add the short hostname to /etc/hosts
too so that ping works.
For those ifcfg files that do have HWADDR and thus can have their
device be unmanaged, we want to read in a much of the connection as
possible since unmanaged devices are tracked via internal NMIfcfgConnection
objects. For BRIDGE/VLAN ifcfg files that don't have HWADDR, we do
want to ignore them completely, but also return a useful error
message.
Previously the code would assume that if the ifcfg file had no backing
connection that we should try to read it in regardless of what the
inotify event was. But if the event was DELETED, there's no point in
trying to read a deleted file in; it's gone. Don't print bogus
warnings about failure to read the long-gone ifcfg file.
If the client was disabled with --with-dhclient=no or
--with-dhcpcd=no, then it's corresponding _PATH will be an empty
string. In that case we want to ignore that client completely
since it was disabled at build time.
Kind of a hack for now, would be better to push down a flag about
whether the update request came in from D-Bus, internally, or from
inotify, but that's a lot more invasive.
Treat them as unmanaged for now so that they dont' need NM_CONTROLLEd=no
which would require further configuration when NM does start to support
these configs.
NMIfupdownConnection really is a subclass of NMSysconfigConnection (as
declared via the G_DEFINE_TYPE macro in nm-ifconfig-connection.c), but
the header incorrectly used NMExportedConnection* in the class and
instance structs. We got away with it because NMSysconfigConnection*
didn't contain anything other than the stuff inherited from
NMExportedConnection*, but it would have caused much trouble if we did
add something.
