Previously the "Enable Wireless" state was somewhat tied to rfkill state,
in that when NM started up, rfkill state would take precedence over what
was listed in the state file, and if you rmmodded your wifi driver and
then modprobed it again after disabling wifi from the menu, wifi would
magically become re-enabled becuase rfkill state changed.
Fix that by creating a third wifi/wwan enable state that tracks the
actual user preference instead of just the rfkill state so that when
the user disables wifi it stays disabled, regardless of what happens
with rfkill.
This means you don't need pm-utils anymore, and that gnome-power-manager
doesn't need to poke NM explicitly for suspend/resume operations.
The old explicit sleep/wake request is still around for pm-utils or
gpm to use, but NM will listen for UPower events and act on them
regardless of what pm-utils or gpm do.
priv->access_list is allocated during object initialization and
only destroyed when the object is destroyed, so it will always
be valid over the lifetime of the object. Thus no need to check
if it exists or not.
The GSList returned by nm_session_manager_get_sessions() must be
freed by the caller. s/connection/self to make it clear what
object is actually being handled here too.
Get rid of the InitInfo struct since it's so small and just store
that information in the main object's private data; less complicated.
Also fix an edge-case where the init-done signal would not get
emitted if CK wasn't tracking any sessions at the time.
While it may not reduce the LOC it saves a few memory allocations
and is somewhat less error prone since callers don't need to free
the returned lists.
Moves the system settings permissions checking into the core service's
permissions checking, which at the same time enables 3-way permission
reporting (yes, no, auth) instead of the old yes/no that we had for
system settings permissions before. This allows UI to show a lock
icon or such when the user could authenticate to gain the permission.
It also moves the wifi-create permissions' namespace to the main
namespace (not .settings) since they really should be checked before
starting a shared wifi connection, rather than having anything to do
with the settings service.
Since these were properties they are harder to validate the caller as
dbus-glib doesn't have any hooks before the property is set. So we
install a low-level dbus filter function to catch property Set
requests before they get to dbus-glib and handle the property access
there.
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.
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.
Just for consistency, make settings related stuff live under the
org.freedesktop.NetworkManager namespace, rather than its own
org.freedesktop.NetworkManagerSettings namespace. Renames are done for
DBus interface names, DBus object paths, and polkit actions.
Remove the org.freedesktop.NetworkManagerSystemSettings bus name and
have everybody talk to org.freedesktop.NetworkManager. Now that we have
a single settings service that's embedded in the main daemon, we don't
need separate names anymore.
NMSysconfigSettings inherited the "bus" property from NMSettingsService.
The property was originally created to allow us to specify what DBus
connection to use, which was important in the days of user settings
services. Now, however, the daemon is the only thing that has a settings
service, and so we can trim a bit of clutter by removing this property
and using NMDBusManager directly.
NMSettingsConnectionInterface was created to allow the daemon and NM
clients to have common code that handled both system and user
connections. It's no longer needed now that user settings services are
gone.
This concludes the flattening of libnm-glib.
The various "update" functions implemented by NMSysconfigConnection have
become confusing. Depending on how you count, we've wound up with about
4 functions that all share the name "update" but nonetheless do
different things. These functions used to be distributed over several
interfaces implemented by NMSysconfigConnection, but now that we've
removed NMExportedConnection and are about to remove
NMSettingsConnectionInterface, they will be all crammed into a single
interface and will be even more confusing than before. It's time to
give better names to these guys.
The renames planned are:
- nm_settings_connection_interface_update() -->
nm_sysconfig_connection_commit_changes()
- nm_sysconfig_connection_update() with signal_update==FALSE -->
nm_sysconfig_connection_replace_settings()
- nm_sysconfig_connection_update() with signal_update==TRUE -->
nm_sysconfig_connection_replace_and_commit()
This commit performs the last two renames. The first will be performed
when removing NMSettingsConnectionInterface.
We also have nm_sysconfig_connection_replace_and_commit() have an
async-ish API that accepts a callback. This fits nicely with the
async-ish API of nm_settings_connection_interface_update(), and it lets
us clean up pk_update_cb() a bit.
NMExportedConnection originally implemented its DBus method call
handlers as virtual functions, primarily so that system and user
settings services could implement them differently.
NMIfupdownConnection also depended on GetSecrets being virtual, so this
was retained when NMExportedConnection was flattened into
NMSysconfigConnection.
However, it turns out that NMIfupdownConnection doesn't really need
these functions to be virtual; it's more appropriate to override the
methods of NMSettingsConnectionInterface (which are used by the DBus
handlers). Indeed, we really don't want settings plugins to override
the DBus handlers, as we must authorize the caller before doing anything
else. So we can save a bunch of code and devirtualize these handlers.
NMSettingsInterface was created to allow code to operate on a settings
service without caring about what kind of settings service it was. Now
that we have just one settings service, this is no longer needed.
More work needs to be done in order to handle errors and permission
settings in an appropriate manner.
In continuation of the theme, the removal of user settings services
means that the distinction between NMSysconfigConnection and
NMExportedConnection is no longer needed. Merge NMExportedConnection
into NMSysconfigConnection.
Much as with nm-remote-settings and nm-remote-settings-system, the
removal of user settings services means there is no more need for
separate interfaces for user and system settings services.
In libnm-glib, this commit merges everything in
nm-settings-system-interface into nm-settings-interface. Alongside with
that, we merge everything in the
org.freedesktop.NetworkManagerSettings.System DBus interface into
org.freedesktop.NetworkManagerSettings.
Now that we have only one settings service, there is no more need to
have common settings service code in libnm-glib. So we can simplify
things somewhat my moving everything from nm-settings-service into
nm-sysconfig-settings.
