The argument name should express what the caller wants
(he wants to know, whether the connection can be activated
for an internal or external activation request).
Whether that involves checking device-specific overrides, is
not the point -- nm_device_check_connection_compatible() is
also a virtual function with device-specific overrides.
There are three configuration options that contain device specs:
'main.ignore-carrier', 'main.no-auto-default', and
'keyfile.unmanaged-devices'.
Unify the parsing of them by splitting the device spec with
nm_match_spec_split(). This changes behavior for parsing of these
properties.
Also get rid of logging warnings when parsing 'keyfile.unmanaged-devices'.
There are currently three device spec properties: 'main.ignore-carrier',
'main.no-auto-default' and 'keyfile.unmanaged-devices'.
The first two, called g_key_file_parse_value_as_string() to split
the string into individual device specs. This uses ',' as separator
and supports escaping using '\\'.
'keyfile.unmanaged-devices' is split using ',' or ';' as separator
without supporting escaping.
Add a new function nm_match_spec_split(), to unify these two behaviors
and support both formats. That is, both previous formats are mostly
supported, but obviously there are some behavioral changes if the string
contains one of '\\', ',', or ';'.
nm_match_spec_split() is copied from glibs g_key_file_parse_value_as_string()
and adjusted.
Extend nm_match_spec_*() to support an "except:" prefix to negate
the result of a match. "except:" only works when followed by
an exact match type, for example "except:interface-name:vboxnet0",
but not "except:vboxnet0".
A matching "except:" spec always wins, regardless of other positive
matchings.
This includes several changes how to match device specs:
- matching the interface name is no longer case-insenstive as
interface names themselves are case-sensitive.
- Now we skip patterns that start with "mac:" or "s390-subchannels:"
for comparing interface names. Previously a spec "mac:1" would have
matched an interface named "mac:1", now it doesn't.
To match such an interface, you would have to specify
"interface-name:mac:1".
- previously, a pattern "a" would have matched an interface
named "interface-name:a", now it doesn't. Since valid interface
name (in the kernel) can be at most 15 characters long, this is
however no problem.
- if the spec has the prefix "interface-name:", we support
simple globbing using GPatternSpec. Globbing without exact
spec type will still not match "vboxnet*" -- with the exception
of "*".
You can disable globbing by putting an '=' immediately
after the ':'.
(a) "interface-name:em1" | matches "em1"
(b) "interface-name:em*" | matches "em", "em1", "em2", etc.
(c) "interface-name:em\*" | matches "em\", "em\1", etc.
(d) "interface-name:=em*" | matches "em*"
(e) "em*" | matches "em*"
This changes behavior, in that we now ignore keyfiles that
start with a dot ('.'). This means, that connection with ids
starting with a dot, will be ignored.
https://bugzilla.gnome.org/show_bug.cgi?id=735824
We have nm_keyfile_plugin_utils_should_ignore_file() to ignore certain
files based on patterns. We also need a matching escape function to
avoid saving connections with a name we would ignore later.
https://bugzilla.gnome.org/show_bug.cgi?id=735824
nmcli -c auto -> colors will only be used when stdout is a terminal
nmcli -c yes -> colors will be enabled unconditionally
nmcli -c no -> colors will be disabled unconditionally
The option allows you to specify custom sorting order.
Default order (when no --order is provided) corresponds to -o "active:name:path"
Examples:
nmcli con show -o name
nmcli con show -o +name
- sort connections by name alphabetically
nmcli con show -o -name
- sort connections by name alphabetically in reverse order
mmcli con show -o active:name
- sort connections first by active status, then by name
mmcli con show -o -path
- sort connections by D-Bus path in reverse order
After refactoring libnm-core to use GBytes instead of
GByteArray/DBUS_TYPE_G_UCHAR_ARRAY, it was forgotten to update
keyfile writer.
This causes keyfile writer to skip the NMSetting8021x:password-raw setting
and raise a g_critical() warning.
Fixes: c43f88907b
==12663== 45 bytes in 1 blocks are definitely lost in loss record 2,464 of 4,708
==12663== at 0x4C29BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==12663== by 0x7F4A6F5: g_malloc (gmem.c:97)
==12663== by 0x7F6301E: g_strdup (gstrfuncs.c:356)
==12663== by 0x4B8AE5: nm_manager_new (nm-manager.c:4793)
==12663== by 0x432F3D: main (main.c:413)
==29353== 620 (+620) (32 (+32) direct, 588 (+588) indirect) bytes in 1 (+1) blocks are definitely lost in loss record 6,905 of 7,076
==29353== at 0x7CDBAC8: g_type_create_instance (gtype.c:1844)
==29353== by 0x7CBF356: g_object_new_internal (gobject.c:1774)
==29353== by 0x7CC0D4C: g_object_newv (gobject.c:1922)
==29353== by 0x7CC14E3: g_object_new (gobject.c:1614)
==29353== by 0x50B58A: nm_secret_agent_new (nm-secret-agent.c:489)
==29353== by 0x50915F: impl_agent_manager_register_with_capabilities (nm-agent-manager.c:309)
==29353== by 0x62649BE: invoke_object_method (dbus-gobject.c:1899)
==29353== by 0x62649BE: object_registration_message (dbus-gobject.c:2161)
==29353== by 0x649D5CE: _dbus_object_tree_dispatch_and_unlock (dbus-object-tree.c:1018)
==29353== by 0x648F193: dbus_connection_dispatch (dbus-connection.c:4718)
==29353== by 0x6261DB4: message_queue_dispatch (dbus-gmain.c:90)
==29353== by 0x7F44AEA: g_main_dispatch (gmain.c:3111)
==29353== by 0x7F44AEA: g_main_context_dispatch (gmain.c:3710)
==29353== by 0x7F44E87: g_main_context_iterate.isra.29 (gmain.c:3781)
==5177== 6 (+6) bytes in 1 (+1) blocks are definitely lost in loss record 118 of 6,581
==5177== at 0x4C29BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==5177== by 0x7F4A6F5: g_malloc (gmem.c:97)
==5177== by 0x7F6301E: g_strdup (gstrfuncs.c:356)
==5177== by 0x4AD902: nm_auth_chain_set_data (nm-auth-utils.c:194)
==5177== by 0x50919E: impl_agent_manager_register_with_capabilities (nm-agent-manager.c:323)
==5177== by 0x62649BE: invoke_object_method (dbus-gobject.c:1899)
==5177== by 0x62649BE: object_registration_message (dbus-gobject.c:2161)
==5177== by 0x649D5CE: _dbus_object_tree_dispatch_and_unlock (dbus-object-tree.c:1018)
==5177== by 0x648F193: dbus_connection_dispatch (dbus-connection.c:4718)
==5177== by 0x6261DB4: message_queue_dispatch (dbus-gmain.c:90)
==5177== by 0x7F44AEA: g_main_dispatch (gmain.c:3111)
==5177== by 0x7F44AEA: g_main_context_dispatch (gmain.c:3710)
==5177== by 0x7F44E87: g_main_context_iterate.isra.29 (gmain.c:3781)
==5177== by 0x7F451B1: g_main_loop_run (gmain.c:3975)
==5177== 104 (+104) bytes in 1 (+1) blocks are definitely lost in loss record 5,502 of 6,581
==5177== at 0x4C29BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==5177== by 0x7F4A6F5: g_malloc (gmem.c:97)
==5177== by 0x7F6159F: g_slice_alloc (gslice.c:1007)
==5177== by 0x7F61B6D: g_slice_alloc0 (gslice.c:1032)
==5177== by 0x7CDB9A3: g_type_create_instance (gtype.c:1847)
==5177== by 0x7CBF356: g_object_new_internal (gobject.c:1774)
==5177== by 0x7CC0D4C: g_object_newv (gobject.c:1922)
==5177== by 0x7CC14E3: g_object_new (gobject.c:1614)
==5177== by 0x79A4C57: g_simple_async_result_new (gsimpleasyncresult.c:319)
==5177== by 0x515B34: nm_connectivity_check_async (nm-connectivity.c:289)
==5177== by 0x515D74: run_check (nm-connectivity.c:217)
==5177== by 0x515DBF: idle_start_periodic_checks (nm-connectivity.c:229)
==1345== Invalid read of size 1
==1345== at 0x827DC15: vfprintf (vfprintf.c:1642)
==1345== by 0x8345D04: __vasprintf_chk (vasprintf_chk.c:66)
==1345== by 0x7F882DB: vasprintf (stdio2.h:210)
==1345== by 0x7F882DB: g_vasprintf (gprintf.c:316)
==1345== by 0x7F6319C: g_strdup_vprintf (gstrfuncs.c:507)
==1345== by 0x7F63258: g_strdup_printf (gstrfuncs.c:533)
==1345== by 0x472833: nm_platform_link_to_string (nm-platform.c:2337)
==1345== by 0x472A05: log_link (nm-platform.c:2754)
==1345== by 0x9DC5D5F: ffi_call_unix64 (unix64.S:76)
==1345== by 0x9DC57D0: ffi_call (ffi64.c:525)
==1345== by 0x7CBA553: g_cclosure_marshal_generic (gclosure.c:1448)
==1345== by 0x7CB9D34: g_closure_invoke (gclosure.c:768)
==1345== by 0x7CCB34B: signal_emit_unlocked_R (gsignal.c:3483)
==1345== Address 0xa91b5a0 is 0 bytes inside a block of size 5 free'd
==1345== at 0x4C2ACE9: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==1345== by 0x68E7D6D: link_free_data (link.c:223)
==1345== by 0x6D47B1F: nl_object_free (object.c:186)
==1345== by 0x46C31C: put_nl_object (nm-linux-platform.c:222)
==1345== by 0x46C31C: link_change (nm-linux-platform.c:2354)
==1345== by 0x46C87F: link_set_user_ipv6ll_enabled (nm-linux-platform.c:2583)
==1345== by 0x4476C4: set_nm_ipv6ll (nm-device.c:4418)
==1345== by 0x4476C4: ip6_managed_setup (nm-device.c:7515)
==1345== by 0x453F12: _set_state_full (nm-device.c:7665)
==1345== by 0x4B6609: add_device (nm-manager.c:1885)
==1345== by 0x4B6880: system_create_virtual_device (nm-manager.c:1126)
==1345== by 0x4B6B40: system_create_virtual_devices (nm-manager.c:1163)
==1345== by 0x4B6E00: platform_link_added (nm-manager.c:2213)
==1345== by 0x4B6E00: platform_link_cb (nm-manager.c:2228)
==1345== by 0x9DC5D5F: ffi_call_unix64 (unix64.S:76)
ndp_close() does not do that -- it only closes the socket. It's safe to call
even if we didn't start solicitation as it has a NULL-check.
==7745== 80 (+80) bytes in 2 (+2) blocks are definitely lost in loss record 3,983 of 5,735
==7745== at 0x4C29BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7745== by 0x6F57A2D: ndp_msgrcv_handler_register (libndp.c:1697)
==7745== by 0x47572E: start (nm-lndp-rdisc.c:691)
==7745== by 0x44A457: addrconf6_start_with_link_ready (nm-device.c:4280)
==7745== by 0x44C1E7: linklocal6_complete (nm-device.c:3931)
==7745== by 0x44C1E7: update_ip_config (nm-device.c:6667)
==7745== by 0x44C2F8: queued_ip_config_change (nm-device.c:6688)
==7745== by 0x7F44AEA: g_main_dispatch (gmain.c:3111)
==7745== by 0x7F44AEA: g_main_context_dispatch (gmain.c:3710)
==7745== by 0x7F44E87: g_main_context_iterate.isra.29 (gmain.c:3781)
==7745== by 0x7F451B1: g_main_loop_run (gmain.c:3975)
==7745== by 0x432F74: main (main.c:460)
==7745== 37 (+37) bytes in 1 (+1) blocks are definitely lost in loss record 2,679 of 5,735
==7745== at 0x4C29BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7745== by 0x7F4A6F5: g_malloc (gmem.c:97)
==7745== by 0x7F6301E: g_strdup (gstrfuncs.c:356)
==7745== by 0x45B097: set_property (nm-dhcp-client.c:851)
==7745== by 0x7CBF688: object_set_property (gobject.c:1415)
==7745== by 0x7CBF688: g_object_new_internal (gobject.c:1808)
==7745== by 0x7CC1194: g_object_new_valist (gobject.c:2034)
==7745== by 0x7CC14D0: g_object_new (gobject.c:1617)
==7745== by 0x45FF9F: client_start (nm-dhcp-manager.c:253)
==7745== by 0x460393: nm_dhcp_manager_start_ip4 (nm-dhcp-manager.c:308)
==7745== by 0x44EB16: dhcp4_start (nm-device.c:3168)
==7745== by 0x44EE15: act_stage3_ip4_config_start (nm-device.c:3440)
==7745== by 0x455C9F: nm_device_activate_stage3_ip4_start (nm-device.c:4657)
==7745== 11 (+11) bytes in 1 (+1) blocks are definitely lost in loss record 408 of 5,735
==7745== at 0x4C29BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7745== by 0x7F4A6F5: g_malloc (gmem.c:97)
==7745== by 0x7F6301E: g_strdup (gstrfuncs.c:356)
==7745== by 0x45C188: nm_dhcp_client_start_ip4 (nm-dhcp-client.c:417)
==7745== by 0x460147: client_start (nm-dhcp-manager.c:268)
==7745== by 0x460393: nm_dhcp_manager_start_ip4 (nm-dhcp-manager.c:308)
==7745== by 0x44EB16: dhcp4_start (nm-device.c:3168)
==7745== by 0x44EE15: act_stage3_ip4_config_start (nm-device.c:3440)
==7745== by 0x455C9F: nm_device_activate_stage3_ip4_start (nm-device.c:4657)
==7745== by 0x456467: nm_device_activate_stage3_ip_config_start (nm-device.c:4801)
==7745== by 0x7F44AEA: g_main_dispatch (gmain.c:3111)
==7745== by 0x7F44AEA: g_main_context_dispatch (gmain.c:3710)
==7745== by 0x7F44E87: g_main_context_iterate.isra.29 (gmain.c:3781)
==4203== 97 (+97) bytes in 2 (+2) blocks are definitely lost in loss record 4,586 of 5,632
==4203== at 0x4C29BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==4203== by 0x7F4A6F5: g_malloc (gmem.c:97)
==4203== by 0x7F6301E: g_strdup (gstrfuncs.c:356)
==4203== by 0x47E4C8: nm_settings_connection_set_filename (nm-settings-connection.c:2228)
==4203== by 0x7CBF6EC: object_set_property (gobject.c:1415)
==4203== by 0x7CBF6EC: g_object_new_internal (gobject.c:1828)
==4203== by 0x7CC1194: g_object_new_valist (gobject.c:2034)
==4203== by 0x7CC14D0: g_object_new (gobject.c:1617)
==4203== by 0x12A08193: nm_ifcfg_connection_new (nm-ifcfg-connection.c:229)
==4203== by 0x12A0542B: update_connection (plugin.c:225)
==4203== by 0x12A0696A: add_connection (plugin.c:715)
==4203== by 0x4814BB: nm_settings_add_connection (nm-settings.c:1030)
==4203== by 0x4817DE: pk_add_cb (nm-settings.c:1136)
Access to connection configuration should not be blocked by absence of a
user session tracked using logind or consolekit. Access control based on
UID is sufficient.
This patch ensures that the user can always access connections even if
he doesn't have a session tracked by logind or consolekit and even when
NetworkManager is not built with logind or consolekit support.
Please note that presence or absence of a session tracked by logind or
consolekit doesn't carry any security information.
Acked-By: Thomas Haller <thaller@redhat.com>
Acked-By: Dan Williams <dcbw@redhat.com>
Agent registration should not be blocked by absence of a user session
tracked using logind or consolekit. Access control based on UID is
sufficient.
This patch ensures that the user can always register a secret agent,
even if he doesn't have a session tracked by logind or consolekit and
even when NetworkManager is not built with logind or consolekit support.
Please note checking for presence or absence of a user session tracked
by logind has no value in this context.
Acked-By: Thomas Haller <thaller@redhat.com>
Acked-By: Dan Williams <dcbw@redhat.com>
