2020-12-23 22:21:36 +01:00
|
|
|
/* SPDX-License-Identifier: LGPL-2.1-or-later */
|
2014-07-24 08:53:33 -04:00
|
|
|
/*
|
2019-10-01 09:20:35 +02:00
|
|
|
* Copyright (C) 2007 - 2013 Red Hat, Inc.
|
|
|
|
|
* Copyright (C) 2007 - 2008 Novell, Inc.
|
2014-07-24 08:53:33 -04:00
|
|
|
*/
|
|
|
|
|
|
2021-02-12 15:01:09 +01:00
|
|
|
#include "libnm-core-impl/nm-default-libnm-core.h"
|
2016-02-19 14:57:48 +01:00
|
|
|
|
2016-02-12 14:44:52 +01:00
|
|
|
#include "nm-setting-connection.h"
|
|
|
|
|
|
2021-05-02 22:42:51 +02:00
|
|
|
#include "libnm-glib-aux/nm-uuid.h"
|
2021-02-12 15:01:09 +01:00
|
|
|
#include "libnm-core-aux-intern/nm-common-macros.h"
|
2014-07-24 08:53:33 -04:00
|
|
|
#include "nm-utils.h"
|
2014-08-21 13:19:53 -04:00
|
|
|
#include "nm-utils-private.h"
|
2015-05-06 10:54:35 +02:00
|
|
|
#include "nm-core-enum-types.h"
|
2014-10-21 22:30:31 -04:00
|
|
|
#include "nm-connection-private.h"
|
2014-10-21 22:09:52 -04:00
|
|
|
#include "nm-setting-bond.h"
|
|
|
|
|
#include "nm-setting-bridge.h"
|
|
|
|
|
#include "nm-setting-team.h"
|
|
|
|
|
#include "nm-setting-vlan.h"
|
2021-02-18 08:13:35 +01:00
|
|
|
#include "libnm-systemd-shared/nm-sd-utils-shared.h"
|
2014-07-24 08:53:33 -04:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* SECTION:nm-setting-connection
|
|
|
|
|
* @short_description: Describes general connection properties
|
|
|
|
|
*
|
|
|
|
|
* The #NMSettingConnection object is a #NMSetting subclass that describes
|
|
|
|
|
* properties that apply to all #NMConnection objects, regardless of what type
|
|
|
|
|
* of network connection they describe. Each #NMConnection object must contain
|
|
|
|
|
* a #NMSettingConnection setting.
|
|
|
|
|
**/
|
|
|
|
|
|
2019-01-11 08:32:54 +01:00
|
|
|
/*****************************************************************************/
|
2014-07-24 08:53:33 -04:00
|
|
|
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
typedef enum _nm_packed {
|
|
|
|
|
PERM_TYPE_INVALID,
|
|
|
|
|
PERM_TYPE_USER,
|
2014-07-24 08:53:33 -04:00
|
|
|
} PermType;
|
|
|
|
|
|
|
|
|
|
typedef struct {
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
PermType ptype;
|
2021-11-09 13:28:54 +01:00
|
|
|
char *item;
|
2014-07-24 08:53:33 -04:00
|
|
|
} Permission;
|
|
|
|
|
|
2019-01-11 08:32:54 +01:00
|
|
|
NM_GOBJECT_PROPERTIES_DEFINE(NMSettingConnection,
|
|
|
|
|
PROP_ID,
|
|
|
|
|
PROP_UUID,
|
|
|
|
|
PROP_INTERFACE_NAME,
|
|
|
|
|
PROP_TYPE,
|
|
|
|
|
PROP_PERMISSIONS,
|
|
|
|
|
PROP_AUTOCONNECT,
|
|
|
|
|
PROP_AUTOCONNECT_PRIORITY,
|
|
|
|
|
PROP_AUTOCONNECT_RETRIES,
|
|
|
|
|
PROP_MULTI_CONNECT,
|
|
|
|
|
PROP_TIMESTAMP,
|
|
|
|
|
PROP_READ_ONLY,
|
|
|
|
|
PROP_ZONE,
|
|
|
|
|
PROP_MASTER,
|
|
|
|
|
PROP_SLAVE_TYPE,
|
|
|
|
|
PROP_AUTOCONNECT_SLAVES,
|
|
|
|
|
PROP_SECONDARIES,
|
|
|
|
|
PROP_GATEWAY_PING_TIMEOUT,
|
|
|
|
|
PROP_METERED,
|
|
|
|
|
PROP_LLDP,
|
|
|
|
|
PROP_MDNS,
|
|
|
|
|
PROP_LLMNR,
|
2021-10-03 19:16:01 +02:00
|
|
|
PROP_DNS_OVER_TLS,
|
2022-07-18 21:24:09 +02:00
|
|
|
PROP_MPTCP_FLAGS,
|
2019-01-11 08:32:54 +01:00
|
|
|
PROP_STABLE_ID,
|
|
|
|
|
PROP_AUTH_RETRIES,
|
2019-07-01 10:01:28 +02:00
|
|
|
PROP_WAIT_DEVICE_TIMEOUT,
|
2022-05-27 12:36:29 +02:00
|
|
|
PROP_MUD_URL,
|
|
|
|
|
PROP_WAIT_ACTIVATION_DELAY, );
|
2019-01-11 08:32:54 +01:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
typedef struct {
|
2022-01-24 17:24:25 +01:00
|
|
|
GArray *permissions;
|
|
|
|
|
NMValueStrv secondaries;
|
|
|
|
|
char *id;
|
|
|
|
|
char *uuid;
|
|
|
|
|
char *stable_id;
|
|
|
|
|
char *interface_name;
|
|
|
|
|
char *type;
|
|
|
|
|
char *master;
|
|
|
|
|
char *slave_type;
|
|
|
|
|
char *zone;
|
|
|
|
|
char *mud_url;
|
|
|
|
|
guint64 timestamp;
|
|
|
|
|
int autoconnect_slaves;
|
|
|
|
|
int metered;
|
|
|
|
|
gint32 autoconnect_priority;
|
|
|
|
|
gint32 autoconnect_retries;
|
|
|
|
|
gint32 multi_connect;
|
|
|
|
|
gint32 auth_retries;
|
|
|
|
|
gint32 mdns;
|
|
|
|
|
gint32 llmnr;
|
|
|
|
|
gint32 dns_over_tls;
|
|
|
|
|
gint32 wait_device_timeout;
|
|
|
|
|
gint32 lldp;
|
2022-05-27 12:36:29 +02:00
|
|
|
gint32 wait_activation_delay;
|
2022-07-18 21:24:09 +02:00
|
|
|
guint32 mptcp_flags;
|
2022-01-24 17:24:25 +01:00
|
|
|
guint32 gateway_ping_timeout;
|
|
|
|
|
bool autoconnect;
|
|
|
|
|
bool read_only;
|
2014-07-24 08:53:33 -04:00
|
|
|
} NMSettingConnectionPrivate;
|
|
|
|
|
|
2021-06-11 00:27:31 +02:00
|
|
|
/**
|
|
|
|
|
* NMSettingConnection:
|
|
|
|
|
*
|
|
|
|
|
* General Connection Profile Settings
|
|
|
|
|
*/
|
|
|
|
|
struct _NMSettingConnection {
|
libnm: embed private structure in NMSetting and avoid g_type_class_add_private()
Historically, the NMSetting types were in public headers. Theoretically,
that allowed users to subtype our classes. However in practice that was
impossible because they lacked required access to internal functions to
fully create an NMSetting class outside of libnm. And it also was not
useful, because you simply cannot extend libnm by subtyping a libnm
class. And supporting such a use case would be hard and limit what we can
do in libnm.
Having GObject structs in public headers also require that we don't
change it's layout. The ABI of those structs must not change, if anybody
out there was actually subclassing our GObjects.
In libnm 1.34 (commit e46d484fae9e ('libnm: hide NMSetting types from
public headers')) we moved the structs from headers to internal.
This would have caused a compiler error if anybody was using those
struct definitions. However, we still didn't change the ABI/layout so
that we didn't break users who relied on it (for whatever reason).
It doesn't seem there were any affected user. We waited long enough.
Change internal ABI.
No longer use g_type_class_add_private(). Instead, embed the private
structs directly (_NM_GET_PRIVATE()) or indirectly
(_NM_GET_PRIVATE_PTR()) in the object.
The main benefit is for debugging in the debugger, where we can now
easily find the private data. Previously that was so cumbersome to be
effectively impossible.
It's also the fastest possible way, since NM_SETTING_*_GET_PRIVATE()
literally resolves to "&self->_priv" (plus static asserts and
nm_assert() for type checking).
_NM_GET_PRIVATE() also propagates constness and requires that the
argument is a compatible pointer type (at compile time).
Note that g_type_class_add_private() is also deprecated in glib 2.58 and
replaced by G_ADD_PRIVATE(). For one, we still don't rely on 2.58. Also,
G_ADD_PRIVATE() is a worse solution as it supports a usecase that we
don't care for (public structs in headers). _NM_GET_PRIVATE() is still
faster, works with older glib and most importantly: is better for
debugging as you can find the private data from an object pointer.
For NMSettingIPConfig this is rather awkward, because all direct
properties require a common "klass->private_offset". This was however
the case before this change. Nothing new here. And if you ever touch
this and do something wrong, many unit tests will fail. It's almost
impossible to get wrong, albeit it can be confusing to understand.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1773
2023-10-24 19:05:50 +02:00
|
|
|
NMSetting parent;
|
|
|
|
|
NMSettingConnectionPrivate _priv;
|
2021-06-11 00:27:31 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct _NMSettingConnectionClass {
|
|
|
|
|
NMSettingClass parent;
|
|
|
|
|
};
|
|
|
|
|
|
2019-01-11 08:32:54 +01:00
|
|
|
G_DEFINE_TYPE(NMSettingConnection, nm_setting_connection, NM_TYPE_SETTING)
|
|
|
|
|
|
|
|
|
|
#define NM_SETTING_CONNECTION_GET_PRIVATE(o) \
|
libnm: embed private structure in NMSetting and avoid g_type_class_add_private()
Historically, the NMSetting types were in public headers. Theoretically,
that allowed users to subtype our classes. However in practice that was
impossible because they lacked required access to internal functions to
fully create an NMSetting class outside of libnm. And it also was not
useful, because you simply cannot extend libnm by subtyping a libnm
class. And supporting such a use case would be hard and limit what we can
do in libnm.
Having GObject structs in public headers also require that we don't
change it's layout. The ABI of those structs must not change, if anybody
out there was actually subclassing our GObjects.
In libnm 1.34 (commit e46d484fae9e ('libnm: hide NMSetting types from
public headers')) we moved the structs from headers to internal.
This would have caused a compiler error if anybody was using those
struct definitions. However, we still didn't change the ABI/layout so
that we didn't break users who relied on it (for whatever reason).
It doesn't seem there were any affected user. We waited long enough.
Change internal ABI.
No longer use g_type_class_add_private(). Instead, embed the private
structs directly (_NM_GET_PRIVATE()) or indirectly
(_NM_GET_PRIVATE_PTR()) in the object.
The main benefit is for debugging in the debugger, where we can now
easily find the private data. Previously that was so cumbersome to be
effectively impossible.
It's also the fastest possible way, since NM_SETTING_*_GET_PRIVATE()
literally resolves to "&self->_priv" (plus static asserts and
nm_assert() for type checking).
_NM_GET_PRIVATE() also propagates constness and requires that the
argument is a compatible pointer type (at compile time).
Note that g_type_class_add_private() is also deprecated in glib 2.58 and
replaced by G_ADD_PRIVATE(). For one, we still don't rely on 2.58. Also,
G_ADD_PRIVATE() is a worse solution as it supports a usecase that we
don't care for (public structs in headers). _NM_GET_PRIVATE() is still
faster, works with older glib and most importantly: is better for
debugging as you can find the private data from an object pointer.
For NMSettingIPConfig this is rather awkward, because all direct
properties require a common "klass->private_offset". This was however
the case before this change. Nothing new here. And if you ever touch
this and do something wrong, many unit tests will fail. It's almost
impossible to get wrong, albeit it can be confusing to understand.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1773
2023-10-24 19:05:50 +02:00
|
|
|
_NM_GET_PRIVATE(o, NMSettingConnection, NM_IS_SETTING_CONNECTION, NMSetting)
|
2014-07-24 08:53:33 -04:00
|
|
|
|
2016-10-02 18:22:50 +02:00
|
|
|
/*****************************************************************************/
|
2014-07-24 08:53:33 -04:00
|
|
|
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
static void
|
|
|
|
|
_permission_set_stale(Permission *permission, PermType ptype, char *item_take)
|
|
|
|
|
{
|
|
|
|
|
nm_assert(permission);
|
|
|
|
|
nm_assert(NM_IN_SET(ptype, PERM_TYPE_INVALID, PERM_TYPE_USER));
|
|
|
|
|
nm_assert(ptype != PERM_TYPE_USER
|
|
|
|
|
|| nm_settings_connection_validate_permission_user(item_take, -1));
|
|
|
|
|
|
|
|
|
|
/* we don't inspect (clear) permission before setting. It takes a
|
|
|
|
|
* stale instance. */
|
|
|
|
|
*permission = (Permission){
|
|
|
|
|
.ptype = ptype,
|
|
|
|
|
.item = item_take,
|
|
|
|
|
};
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
_permission_clear_stale(Permission *permission)
|
|
|
|
|
{
|
|
|
|
|
g_free(permission->item);
|
|
|
|
|
/* We leave the permission instance with dangling pointers.
|
|
|
|
|
* It is "stale". */
|
|
|
|
|
}
|
2014-07-24 08:53:33 -04:00
|
|
|
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
static gboolean
|
|
|
|
|
_permission_set_stale_parse(Permission *permission, const char *str)
|
2014-07-24 08:53:33 -04:00
|
|
|
{
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
const char *str0 = str;
|
2014-07-24 08:53:33 -04:00
|
|
|
const char *last_colon;
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
gsize ulen;
|
|
|
|
|
|
|
|
|
|
nm_assert(str);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
if (!str)
|
|
|
|
|
goto invalid;
|
|
|
|
|
|
|
|
|
|
if (!NM_STR_HAS_PREFIX(str, NM_SETTINGS_CONNECTION_PERMISSION_USER_PREFIX))
|
|
|
|
|
goto invalid;
|
|
|
|
|
|
|
|
|
|
str += NM_STRLEN(NM_SETTINGS_CONNECTION_PERMISSION_USER_PREFIX);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
last_colon = strrchr(str, ':');
|
|
|
|
|
if (last_colon) {
|
|
|
|
|
/* Reject :[detail] for now */
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
if (last_colon[1] != '\0')
|
|
|
|
|
goto invalid;
|
2014-07-24 08:53:33 -04:00
|
|
|
ulen = last_colon - str;
|
|
|
|
|
} else
|
|
|
|
|
ulen = strlen(str);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
if (!nm_settings_connection_validate_permission_user(str, ulen))
|
|
|
|
|
goto invalid;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
/* Yay, valid... create the new permission */
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
if (permission)
|
|
|
|
|
_permission_set_stale(permission, PERM_TYPE_USER, g_strndup(str, ulen));
|
|
|
|
|
return TRUE;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
invalid:
|
|
|
|
|
if (permission)
|
|
|
|
|
_permission_set_stale(permission, PERM_TYPE_INVALID, g_strdup(str0));
|
|
|
|
|
return FALSE;
|
2014-07-24 08:53:33 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static char *
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
_permission_to_string(Permission *permission)
|
2014-07-24 08:53:33 -04:00
|
|
|
{
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
nm_assert(permission);
|
|
|
|
|
|
|
|
|
|
switch (permission->ptype) {
|
|
|
|
|
case PERM_TYPE_USER:
|
|
|
|
|
return g_strdup_printf(NM_SETTINGS_CONNECTION_PERMISSION_USER_PREFIX "%s:",
|
|
|
|
|
permission->item);
|
|
|
|
|
case PERM_TYPE_INVALID:
|
|
|
|
|
nm_assert(permission->item);
|
|
|
|
|
return g_strdup(permission->item);
|
|
|
|
|
}
|
|
|
|
|
nm_assert_not_reached();
|
|
|
|
|
return g_strdup(permission->item ?: "");
|
2014-07-24 08:53:33 -04:00
|
|
|
}
|
|
|
|
|
|
2016-10-02 18:22:50 +02:00
|
|
|
/*****************************************************************************/
|
2014-07-24 08:53:33 -04:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_get_id:
|
|
|
|
|
* @setting: the #NMSettingConnection
|
|
|
|
|
*
|
|
|
|
|
* Returns the #NMSettingConnection:id property of the connection.
|
|
|
|
|
*
|
|
|
|
|
* Returns: the connection ID
|
|
|
|
|
**/
|
|
|
|
|
const char *
|
|
|
|
|
nm_setting_connection_get_id(NMSettingConnection *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), NULL);
|
|
|
|
|
|
|
|
|
|
return NM_SETTING_CONNECTION_GET_PRIVATE(setting)->id;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_get_uuid:
|
|
|
|
|
* @setting: the #NMSettingConnection
|
|
|
|
|
*
|
|
|
|
|
* Returns the #NMSettingConnection:uuid property of the connection.
|
|
|
|
|
*
|
|
|
|
|
* Returns: the connection UUID
|
|
|
|
|
**/
|
|
|
|
|
const char *
|
|
|
|
|
nm_setting_connection_get_uuid(NMSettingConnection *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), NULL);
|
|
|
|
|
|
|
|
|
|
return NM_SETTING_CONNECTION_GET_PRIVATE(setting)->uuid;
|
|
|
|
|
}
|
|
|
|
|
|
2016-06-21 16:41:05 +02:00
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_get_stable_id:
|
|
|
|
|
* @setting: the #NMSettingConnection
|
|
|
|
|
*
|
|
|
|
|
* Returns the #NMSettingConnection:stable_id property of the connection.
|
|
|
|
|
*
|
|
|
|
|
* Returns: the stable-id for the connection
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.4
|
|
|
|
|
**/
|
|
|
|
|
const char *
|
|
|
|
|
nm_setting_connection_get_stable_id(NMSettingConnection *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), NULL);
|
|
|
|
|
|
|
|
|
|
return NM_SETTING_CONNECTION_GET_PRIVATE(setting)->stable_id;
|
|
|
|
|
}
|
|
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_get_interface_name:
|
|
|
|
|
* @setting: the #NMSettingConnection
|
|
|
|
|
*
|
|
|
|
|
* Returns the #NMSettingConnection:interface-name property of the connection.
|
|
|
|
|
*
|
|
|
|
|
* Returns: the connection's interface name
|
|
|
|
|
**/
|
|
|
|
|
const char *
|
|
|
|
|
nm_setting_connection_get_interface_name(NMSettingConnection *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), NULL);
|
|
|
|
|
|
|
|
|
|
return NM_SETTING_CONNECTION_GET_PRIVATE(setting)->interface_name;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_get_connection_type:
|
|
|
|
|
* @setting: the #NMSettingConnection
|
|
|
|
|
*
|
|
|
|
|
* Returns the #NMSettingConnection:type property of the connection.
|
|
|
|
|
*
|
|
|
|
|
* Returns: the connection type
|
|
|
|
|
**/
|
|
|
|
|
const char *
|
|
|
|
|
nm_setting_connection_get_connection_type(NMSettingConnection *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), NULL);
|
|
|
|
|
|
|
|
|
|
return NM_SETTING_CONNECTION_GET_PRIVATE(setting)->type;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_get_num_permissions:
|
|
|
|
|
* @setting: the #NMSettingConnection
|
|
|
|
|
*
|
2017-05-05 14:11:05 +02:00
|
|
|
* Returns the number of entries in the #NMSettingConnection:permissions
|
2014-07-24 08:53:33 -04:00
|
|
|
* property of this setting.
|
|
|
|
|
*
|
2017-05-05 14:11:05 +02:00
|
|
|
* Returns: the number of permissions entries
|
2014-07-24 08:53:33 -04:00
|
|
|
*/
|
|
|
|
|
guint32
|
|
|
|
|
nm_setting_connection_get_num_permissions(NMSettingConnection *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), 0);
|
|
|
|
|
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
return nm_g_array_len(NM_SETTING_CONNECTION_GET_PRIVATE(setting)->permissions);
|
2014-07-24 08:53:33 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_get_permission:
|
|
|
|
|
* @setting: the #NMSettingConnection
|
|
|
|
|
* @idx: the zero-based index of the permissions entry
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
* @out_ptype: on return, the permission type. This is currently always "user",
|
|
|
|
|
* unless the entry is invalid, in which case it returns "invalid".
|
2018-09-15 07:20:54 -04:00
|
|
|
* @out_pitem: on return, the permission item (formatted according to @ptype, see
|
2014-07-24 08:53:33 -04:00
|
|
|
* #NMSettingConnection:permissions for more detail
|
|
|
|
|
* @out_detail: on return, the permission detail (at this time, always %NULL)
|
|
|
|
|
*
|
|
|
|
|
* Retrieve one of the entries of the #NMSettingConnection:permissions property
|
|
|
|
|
* of this setting.
|
|
|
|
|
*
|
|
|
|
|
* Returns: %TRUE if a permission was returned, %FALSE if @idx was invalid
|
|
|
|
|
*/
|
|
|
|
|
gboolean
|
|
|
|
|
nm_setting_connection_get_permission(NMSettingConnection *setting,
|
|
|
|
|
guint32 idx,
|
2021-11-09 13:28:54 +01:00
|
|
|
const char **out_ptype,
|
|
|
|
|
const char **out_pitem,
|
|
|
|
|
const char **out_detail)
|
2014-07-24 08:53:33 -04:00
|
|
|
{
|
|
|
|
|
NMSettingConnectionPrivate *priv;
|
2021-11-09 13:28:54 +01:00
|
|
|
Permission *permission;
|
2014-07-24 08:53:33 -04:00
|
|
|
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), FALSE);
|
|
|
|
|
|
|
|
|
|
priv = NM_SETTING_CONNECTION_GET_PRIVATE(setting);
|
|
|
|
|
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
g_return_val_if_fail(idx < nm_g_array_len(priv->permissions), FALSE);
|
2014-07-24 08:53:33 -04:00
|
|
|
|
2022-09-08 12:05:56 +02:00
|
|
|
permission = &nm_g_array_index(priv->permissions, Permission, idx);
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
switch (permission->ptype) {
|
|
|
|
|
case PERM_TYPE_USER:
|
|
|
|
|
NM_SET_OUT(out_ptype, NM_SETTINGS_CONNECTION_PERMISSION_USER);
|
|
|
|
|
NM_SET_OUT(out_pitem, permission->item);
|
|
|
|
|
NM_SET_OUT(out_detail, NULL);
|
|
|
|
|
return TRUE;
|
|
|
|
|
case PERM_TYPE_INVALID:
|
|
|
|
|
goto invalid;
|
|
|
|
|
}
|
|
|
|
|
nm_assert_not_reached();
|
|
|
|
|
invalid:
|
|
|
|
|
NM_SET_OUT(out_ptype, "invalid");
|
|
|
|
|
NM_SET_OUT(out_pitem, permission->item);
|
|
|
|
|
NM_SET_OUT(out_detail, NULL);
|
2014-07-24 08:53:33 -04:00
|
|
|
return TRUE;
|
|
|
|
|
}
|
|
|
|
|
|
2023-10-23 12:11:33 +02:00
|
|
|
static gboolean
|
|
|
|
|
_permissions_user_allowed(NMSettingConnection *setting, const char *uname, gulong uid)
|
2014-07-24 08:53:33 -04:00
|
|
|
{
|
2023-10-23 13:19:26 +02:00
|
|
|
gs_free struct passwd *pw = NULL;
|
2014-07-24 08:53:33 -04:00
|
|
|
NMSettingConnectionPrivate *priv;
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
guint i;
|
2014-07-24 08:53:33 -04:00
|
|
|
|
2023-11-15 10:38:18 +01:00
|
|
|
nm_assert(NM_IS_SETTING_CONNECTION(setting));
|
2014-07-24 08:53:33 -04:00
|
|
|
|
|
|
|
|
priv = NM_SETTING_CONNECTION_GET_PRIVATE(setting);
|
|
|
|
|
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
if (nm_g_array_len(priv->permissions) == 0) {
|
|
|
|
|
/* If no permissions, visible to all */
|
2014-07-24 08:53:33 -04:00
|
|
|
return TRUE;
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
}
|
2014-07-24 08:53:33 -04:00
|
|
|
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
for (i = 0; i < priv->permissions->len; i++) {
|
2022-09-08 12:05:56 +02:00
|
|
|
const Permission *permission = &nm_g_array_index(priv->permissions, Permission, i);
|
2014-07-24 08:53:33 -04:00
|
|
|
|
2023-10-23 12:11:33 +02:00
|
|
|
if (permission->ptype != PERM_TYPE_USER)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
if (!uname) {
|
2023-10-23 13:19:26 +02:00
|
|
|
if (uid != G_MAXULONG) {
|
|
|
|
|
pw = nm_getpwuid(uid);
|
|
|
|
|
uname = nm_passwd_name(pw);
|
|
|
|
|
}
|
|
|
|
|
if (!uname)
|
2023-10-23 12:11:33 +02:00
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (nm_streq(permission->item, uname))
|
2014-07-24 08:53:33 -04:00
|
|
|
return TRUE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
|
2023-10-23 12:11:33 +02:00
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_permissions_user_allowed:
|
|
|
|
|
* @setting: the #NMSettingConnection
|
|
|
|
|
* @uname: the user name to check permissions for
|
|
|
|
|
*
|
|
|
|
|
* Checks whether the given username is allowed to view/access this connection.
|
|
|
|
|
*
|
|
|
|
|
* Returns: %TRUE if the requested user is allowed to view this connection,
|
|
|
|
|
* %FALSE if the given user is not allowed to view this connection
|
|
|
|
|
*/
|
|
|
|
|
gboolean
|
|
|
|
|
nm_setting_connection_permissions_user_allowed(NMSettingConnection *setting, const char *uname)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), FALSE);
|
|
|
|
|
g_return_val_if_fail(uname != NULL, FALSE);
|
|
|
|
|
|
|
|
|
|
return _permissions_user_allowed(setting, uname, G_MAXULONG);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
gboolean
|
|
|
|
|
nm_setting_connection_permissions_user_allowed_by_uid(NMSettingConnection *setting, gulong uid)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), FALSE);
|
|
|
|
|
|
|
|
|
|
return _permissions_user_allowed(setting, NULL, uid);
|
|
|
|
|
}
|
|
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_add_permission:
|
|
|
|
|
* @setting: the #NMSettingConnection
|
|
|
|
|
* @ptype: the permission type; at this time only "user" is supported
|
|
|
|
|
* @pitem: the permission item formatted as required for @ptype
|
2023-03-01 01:21:38 +01:00
|
|
|
* @detail: (nullable): unused at this time; must be %NULL
|
2014-07-24 08:53:33 -04:00
|
|
|
*
|
|
|
|
|
* Adds a permission to the connection's permission list. At this time, only
|
|
|
|
|
* the "user" permission type is supported, and @pitem must be a username. See
|
|
|
|
|
* #NMSettingConnection:permissions: for more details.
|
|
|
|
|
*
|
|
|
|
|
* Returns: %TRUE if the permission was unique and was successfully added to the
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
* list, %FALSE if @ptype or @pitem was invalid.
|
|
|
|
|
* If the permission was already present in the list, it will not be added
|
|
|
|
|
* a second time but %TRUE will be returned. Note that before 1.28, in this
|
|
|
|
|
* case %FALSE would be returned.
|
2014-07-24 08:53:33 -04:00
|
|
|
*/
|
|
|
|
|
gboolean
|
|
|
|
|
nm_setting_connection_add_permission(NMSettingConnection *setting,
|
2021-11-09 13:28:54 +01:00
|
|
|
const char *ptype,
|
|
|
|
|
const char *pitem,
|
|
|
|
|
const char *detail)
|
2014-07-24 08:53:33 -04:00
|
|
|
{
|
|
|
|
|
NMSettingConnectionPrivate *priv;
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
guint i;
|
2014-07-24 08:53:33 -04:00
|
|
|
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), FALSE);
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
g_return_val_if_fail(ptype, FALSE);
|
|
|
|
|
g_return_val_if_fail(pitem, FALSE);
|
2014-07-24 08:53:33 -04:00
|
|
|
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
if (!nm_streq0(ptype, NM_SETTINGS_CONNECTION_PERMISSION_USER))
|
|
|
|
|
return FALSE;
|
|
|
|
|
|
|
|
|
|
if (!nm_settings_connection_validate_permission_user(pitem, -1))
|
|
|
|
|
return FALSE;
|
|
|
|
|
|
|
|
|
|
if (detail)
|
|
|
|
|
return FALSE;
|
2014-07-24 08:53:33 -04:00
|
|
|
|
|
|
|
|
priv = NM_SETTING_CONNECTION_GET_PRIVATE(setting);
|
|
|
|
|
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
if (!priv->permissions) {
|
|
|
|
|
priv->permissions = g_array_sized_new(FALSE, FALSE, sizeof(Permission), 1);
|
|
|
|
|
g_array_set_clear_func(priv->permissions, (GDestroyNotify) _permission_clear_stale);
|
2014-07-24 08:53:33 -04:00
|
|
|
}
|
|
|
|
|
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
for (i = 0; i < priv->permissions->len; i++) {
|
2022-09-08 12:05:56 +02:00
|
|
|
const Permission *permission = &nm_g_array_index(priv->permissions, Permission, i);
|
2014-07-24 08:53:33 -04:00
|
|
|
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
if (permission->ptype == PERM_TYPE_USER && nm_streq(permission->item, pitem))
|
|
|
|
|
return TRUE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
_permission_set_stale(nm_g_array_append_new(priv->permissions, Permission),
|
|
|
|
|
PERM_TYPE_USER,
|
|
|
|
|
g_strdup(pitem));
|
|
|
|
|
_notify(setting, PROP_PERMISSIONS);
|
2014-07-24 08:53:33 -04:00
|
|
|
return TRUE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_remove_permission:
|
|
|
|
|
* @setting: the #NMSettingConnection
|
|
|
|
|
* @idx: the zero-based index of the permission to remove
|
|
|
|
|
*
|
|
|
|
|
* Removes the permission at index @idx from the connection.
|
|
|
|
|
*/
|
|
|
|
|
void
|
|
|
|
|
nm_setting_connection_remove_permission(NMSettingConnection *setting, guint32 idx)
|
|
|
|
|
{
|
|
|
|
|
NMSettingConnectionPrivate *priv;
|
|
|
|
|
|
|
|
|
|
g_return_if_fail(NM_IS_SETTING_CONNECTION(setting));
|
|
|
|
|
|
|
|
|
|
priv = NM_SETTING_CONNECTION_GET_PRIVATE(setting);
|
|
|
|
|
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
g_return_if_fail(idx < nm_g_array_len(priv->permissions));
|
|
|
|
|
|
|
|
|
|
g_array_remove_index(priv->permissions, idx);
|
|
|
|
|
|
2019-01-11 08:28:26 +01:00
|
|
|
_notify(setting, PROP_PERMISSIONS);
|
2014-07-24 08:53:33 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_remove_permission_by_value:
|
|
|
|
|
* @setting: the #NMSettingConnection
|
|
|
|
|
* @ptype: the permission type; at this time only "user" is supported
|
|
|
|
|
* @pitem: the permission item formatted as required for @ptype
|
2023-03-01 01:21:38 +01:00
|
|
|
* @detail: (nullable): unused at this time; must be %NULL
|
2014-07-24 08:53:33 -04:00
|
|
|
*
|
|
|
|
|
* Removes the permission from the connection.
|
|
|
|
|
* At this time, only the "user" permission type is supported, and @pitem must
|
|
|
|
|
* be a username. See #NMSettingConnection:permissions: for more details.
|
|
|
|
|
*
|
|
|
|
|
* Returns: %TRUE if the permission was found and removed; %FALSE if it was not.
|
|
|
|
|
*/
|
|
|
|
|
gboolean
|
|
|
|
|
nm_setting_connection_remove_permission_by_value(NMSettingConnection *setting,
|
2021-11-09 13:28:54 +01:00
|
|
|
const char *ptype,
|
|
|
|
|
const char *pitem,
|
|
|
|
|
const char *detail)
|
2014-07-24 08:53:33 -04:00
|
|
|
{
|
|
|
|
|
NMSettingConnectionPrivate *priv;
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
guint i;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), FALSE);
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
g_return_val_if_fail(ptype, FALSE);
|
|
|
|
|
g_return_val_if_fail(pitem, FALSE);
|
|
|
|
|
|
|
|
|
|
if (!nm_streq0(ptype, NM_SETTINGS_CONNECTION_PERMISSION_USER))
|
|
|
|
|
return FALSE;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
if (detail)
|
|
|
|
|
return FALSE;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
priv = NM_SETTING_CONNECTION_GET_PRIVATE(setting);
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
if (priv->permissions) {
|
|
|
|
|
for (i = 0; i < priv->permissions->len; i++) {
|
2022-09-08 12:05:56 +02:00
|
|
|
const Permission *permission = &nm_g_array_index(priv->permissions, Permission, i);
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
|
|
|
|
|
if (permission->ptype == PERM_TYPE_USER && nm_streq(permission->item, pitem)) {
|
|
|
|
|
g_array_remove_index(priv->permissions, i);
|
|
|
|
|
_notify(setting, PROP_PERMISSIONS);
|
|
|
|
|
return TRUE;
|
|
|
|
|
}
|
2014-07-24 08:53:33 -04:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_get_autoconnect:
|
|
|
|
|
* @setting: the #NMSettingConnection
|
|
|
|
|
*
|
|
|
|
|
* Returns the #NMSettingConnection:autoconnect property of the connection.
|
|
|
|
|
*
|
|
|
|
|
* Returns: the connection's autoconnect behavior
|
|
|
|
|
**/
|
|
|
|
|
gboolean
|
|
|
|
|
nm_setting_connection_get_autoconnect(NMSettingConnection *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), FALSE);
|
|
|
|
|
|
|
|
|
|
return NM_SETTING_CONNECTION_GET_PRIVATE(setting)->autoconnect;
|
|
|
|
|
}
|
|
|
|
|
|
2014-08-25 20:39:40 +02:00
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_get_autoconnect_priority:
|
|
|
|
|
* @setting: the #NMSettingConnection
|
|
|
|
|
*
|
|
|
|
|
* Returns the #NMSettingConnection:autoconnect-priority property of the connection.
|
|
|
|
|
* The higher number, the higher priority.
|
|
|
|
|
*
|
|
|
|
|
* Returns: the connection's autoconnect priority
|
|
|
|
|
**/
|
all: don't use gchar/gshort/gint/glong but C types
We commonly don't use the glib typedefs for char/short/int/long,
but their C types directly.
$ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l
587
$ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l
21114
One could argue that using the glib typedefs is preferable in
public API (of our glib based libnm library) or where it clearly
is related to glib, like during
g_object_set (obj, PROPERTY, (gint) value, NULL);
However, that argument does not seem strong, because in practice we don't
follow that argument today, and seldomly use the glib typedefs.
Also, the style guide for this would be hard to formalize, because
"using them where clearly related to a glib" is a very loose suggestion.
Also note that glib typedefs will always just be typedefs of the
underlying C types. There is no danger of glib changing the meaning
of these typedefs (because that would be a major API break of glib).
A simple style guide is instead: don't use these typedefs.
No manual actions, I only ran the bash script:
FILES=($(git ls-files '*.[hc]'))
sed -i \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\> /\1 /g' \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \
"${FILES[@]}"
2018-07-11 07:40:19 +02:00
|
|
|
int
|
2014-08-25 20:39:40 +02:00
|
|
|
nm_setting_connection_get_autoconnect_priority(NMSettingConnection *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), 0);
|
|
|
|
|
|
|
|
|
|
return NM_SETTING_CONNECTION_GET_PRIVATE(setting)->autoconnect_priority;
|
|
|
|
|
}
|
|
|
|
|
|
2016-10-08 10:27:15 +02:00
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_get_autoconnect_retries:
|
|
|
|
|
* @setting: the #NMSettingConnection
|
|
|
|
|
*
|
|
|
|
|
* Returns the #NMSettingConnection:autoconnect-retries property of the connection.
|
|
|
|
|
* Zero means infinite, -1 means the global default value.
|
|
|
|
|
*
|
|
|
|
|
* Returns: the connection's autoconnect retries
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.6
|
|
|
|
|
**/
|
all: don't use gchar/gshort/gint/glong but C types
We commonly don't use the glib typedefs for char/short/int/long,
but their C types directly.
$ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l
587
$ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l
21114
One could argue that using the glib typedefs is preferable in
public API (of our glib based libnm library) or where it clearly
is related to glib, like during
g_object_set (obj, PROPERTY, (gint) value, NULL);
However, that argument does not seem strong, because in practice we don't
follow that argument today, and seldomly use the glib typedefs.
Also, the style guide for this would be hard to formalize, because
"using them where clearly related to a glib" is a very loose suggestion.
Also note that glib typedefs will always just be typedefs of the
underlying C types. There is no danger of glib changing the meaning
of these typedefs (because that would be a major API break of glib).
A simple style guide is instead: don't use these typedefs.
No manual actions, I only ran the bash script:
FILES=($(git ls-files '*.[hc]'))
sed -i \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\> /\1 /g' \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \
"${FILES[@]}"
2018-07-11 07:40:19 +02:00
|
|
|
int
|
2016-10-08 10:27:15 +02:00
|
|
|
nm_setting_connection_get_autoconnect_retries(NMSettingConnection *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), -1);
|
|
|
|
|
|
|
|
|
|
return NM_SETTING_CONNECTION_GET_PRIVATE(setting)->autoconnect_retries;
|
|
|
|
|
}
|
|
|
|
|
|
all: add connection.multi-connect property for wildcard profiles
Add a new option that allows to activate a profile multiple times
(at the same time). Previoulsy, all profiles were implicitly
NM_SETTING_CONNECTION_MULTI_CONNECT_SINGLE, meaning, that activating
a profile that is already active will deactivate it first.
This will make more sense, as we also add more match-options how
profiles can be restricted to particular devices. We already have
connection.type, connection.interface-name, and (ethernet|wifi).mac-address
to restrict a profile to particular devices. For example, it is however
not possible to specify a wildcard like "eth*" to match a profile to
a set of devices by interface-name. That is another missing feature,
and once we extend the matching capabilities, it makes more sense to
activate a profile multiple times.
See also https://bugzilla.redhat.com/show_bug.cgi?id=997998, which
previously changed that a connection is restricted to a single activation
at a time. This work relaxes that again.
This only adds the new property, it is not used nor implemented yet.
https://bugzilla.redhat.com/show_bug.cgi?id=1555012
2018-04-10 11:45:35 +02:00
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_get_multi_connect:
|
|
|
|
|
* @setting: the #NMSettingConnection
|
|
|
|
|
*
|
|
|
|
|
* Returns: the #NMSettingConnection:multi-connect property of the connection.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.14
|
|
|
|
|
**/
|
|
|
|
|
NMConnectionMultiConnect
|
|
|
|
|
nm_setting_connection_get_multi_connect(NMSettingConnection *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), -1);
|
|
|
|
|
|
|
|
|
|
return (NMConnectionMultiConnect) NM_SETTING_CONNECTION_GET_PRIVATE(setting)->multi_connect;
|
|
|
|
|
}
|
|
|
|
|
|
2017-11-02 09:25:40 +01:00
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_get_auth_retries:
|
|
|
|
|
* @setting: the #NMSettingConnection
|
|
|
|
|
*
|
|
|
|
|
* Returns the value contained in the #NMSettingConnection:auth-retries property.
|
|
|
|
|
*
|
|
|
|
|
* Returns: the configured authentication retries. Zero means
|
|
|
|
|
* infinity and -1 means a global default value.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.10
|
|
|
|
|
**/
|
all: don't use gchar/gshort/gint/glong but C types
We commonly don't use the glib typedefs for char/short/int/long,
but their C types directly.
$ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l
587
$ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l
21114
One could argue that using the glib typedefs is preferable in
public API (of our glib based libnm library) or where it clearly
is related to glib, like during
g_object_set (obj, PROPERTY, (gint) value, NULL);
However, that argument does not seem strong, because in practice we don't
follow that argument today, and seldomly use the glib typedefs.
Also, the style guide for this would be hard to formalize, because
"using them where clearly related to a glib" is a very loose suggestion.
Also note that glib typedefs will always just be typedefs of the
underlying C types. There is no danger of glib changing the meaning
of these typedefs (because that would be a major API break of glib).
A simple style guide is instead: don't use these typedefs.
No manual actions, I only ran the bash script:
FILES=($(git ls-files '*.[hc]'))
sed -i \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\> /\1 /g' \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \
"${FILES[@]}"
2018-07-11 07:40:19 +02:00
|
|
|
int
|
2017-11-02 09:25:40 +01:00
|
|
|
nm_setting_connection_get_auth_retries(NMSettingConnection *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), -1);
|
|
|
|
|
|
|
|
|
|
return NM_SETTING_CONNECTION_GET_PRIVATE(setting)->auth_retries;
|
|
|
|
|
}
|
|
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_get_timestamp:
|
|
|
|
|
* @setting: the #NMSettingConnection
|
|
|
|
|
*
|
|
|
|
|
* Returns the #NMSettingConnection:timestamp property of the connection.
|
|
|
|
|
*
|
|
|
|
|
* Returns: the connection's timestamp
|
|
|
|
|
**/
|
|
|
|
|
guint64
|
|
|
|
|
nm_setting_connection_get_timestamp(NMSettingConnection *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), 0);
|
|
|
|
|
|
|
|
|
|
return NM_SETTING_CONNECTION_GET_PRIVATE(setting)->timestamp;
|
|
|
|
|
}
|
|
|
|
|
|
2019-06-27 09:09:06 +02:00
|
|
|
static GVariant *
|
libnm: use macros function arguments for NMSettInfoPropertType
These functions tend to have many arguments. They are also quite som
boilerplate to implement the hundereds of properties we have, while
we want that properties have common behaviors and similarities.
Instead of repeatedly spelling out the function arguments, use a macro.
Advantages:
- the usage of a _NM_SETT_INFO_PROP_*_FCN_ARGS macro signals that this
is an implementation of a property. You can now grep for these macros
to find all implementation. That was previously rather imprecise, you
could only `git grep '\.to_dbus_fcn'` to find the uses, but not the
implementations.
As the goal is to keep properties "similar", there is a desire to
reduce the number of similar implementations and to find them.
- changing the arguments now no longer will require you to go through
all implementations. At least not, if you merely add an argument that
has a reasonable default behavior and does not require explicit
handling by most implementation.
- it's convenient to be able to patch the argument list to let the
compiler help to reason about something. For example, the
"connection_dict" argument to from_dbus_fcn() is usually unused.
If you'd like to find who uses it, rename the parameter, and
review the (few) compiler errors.
- it does save 573 LOC of boilerplate with no actual logic or useful
information. I argue, that this simplifies the code and review, by
increasing the relative amount of actually meaningful code.
Disadvantages:
- the user no longer directly sees the argument list. They would need
cscope/ctags or an IDE to jump to the macro definition and conveniently
see all arguments.
Also use _nm_nil, so that clang-format interprets this as a function
parameter list. Otherwise, it formats the function differently.
2021-07-26 23:45:31 +02:00
|
|
|
_to_dbus_fcn_timestamp(_NM_SETT_INFO_PROP_TO_DBUS_FCN_ARGS _nm_nil)
|
2019-06-27 09:09:06 +02:00
|
|
|
{
|
|
|
|
|
guint64 v;
|
|
|
|
|
|
|
|
|
|
v = options && options->timestamp.has ? options->timestamp.val
|
|
|
|
|
: NM_SETTING_CONNECTION_GET_PRIVATE(setting)->timestamp;
|
|
|
|
|
|
|
|
|
|
if (v == 0u)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
return g_variant_new_uint64(v);
|
|
|
|
|
}
|
|
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_get_read_only:
|
|
|
|
|
* @setting: the #NMSettingConnection
|
|
|
|
|
*
|
|
|
|
|
* Returns the #NMSettingConnection:read-only property of the connection.
|
|
|
|
|
*
|
|
|
|
|
* Returns: %TRUE if the connection is read-only, %FALSE if it is not
|
2023-03-14 08:48:07 +01:00
|
|
|
*
|
|
|
|
|
* Deprecated: 1.44: This property is deprecated and has no meaning.
|
2014-07-24 08:53:33 -04:00
|
|
|
**/
|
|
|
|
|
gboolean
|
|
|
|
|
nm_setting_connection_get_read_only(NMSettingConnection *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), TRUE);
|
|
|
|
|
|
|
|
|
|
return NM_SETTING_CONNECTION_GET_PRIVATE(setting)->read_only;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_get_zone:
|
|
|
|
|
* @setting: the #NMSettingConnection
|
|
|
|
|
*
|
|
|
|
|
* Returns the #NMSettingConnection:zone property of the connection.
|
|
|
|
|
*
|
|
|
|
|
* Returns: the trust level of a connection
|
|
|
|
|
**/
|
|
|
|
|
const char *
|
|
|
|
|
nm_setting_connection_get_zone(NMSettingConnection *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), NULL);
|
|
|
|
|
|
|
|
|
|
return NM_SETTING_CONNECTION_GET_PRIVATE(setting)->zone;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_get_master:
|
|
|
|
|
* @setting: the #NMSettingConnection
|
|
|
|
|
*
|
|
|
|
|
* Returns the #NMSettingConnection:master property of the connection.
|
|
|
|
|
*
|
|
|
|
|
* Returns: interface name of the master device or UUID of the master
|
|
|
|
|
* connection.
|
|
|
|
|
*/
|
|
|
|
|
const char *
|
|
|
|
|
nm_setting_connection_get_master(NMSettingConnection *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), NULL);
|
|
|
|
|
|
|
|
|
|
return NM_SETTING_CONNECTION_GET_PRIVATE(setting)->master;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_get_slave_type:
|
|
|
|
|
* @setting: the #NMSettingConnection
|
|
|
|
|
*
|
|
|
|
|
* Returns the #NMSettingConnection:slave-type property of the connection.
|
|
|
|
|
*
|
|
|
|
|
* Returns: the type of slave this connection is, if any
|
|
|
|
|
*/
|
|
|
|
|
const char *
|
|
|
|
|
nm_setting_connection_get_slave_type(NMSettingConnection *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), NULL);
|
|
|
|
|
|
|
|
|
|
return NM_SETTING_CONNECTION_GET_PRIVATE(setting)->slave_type;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_is_slave_type:
|
|
|
|
|
* @setting: the #NMSettingConnection
|
|
|
|
|
* @type: the setting name (ie #NM_SETTING_BOND_SETTING_NAME) to be matched
|
|
|
|
|
* against @setting's slave type
|
|
|
|
|
*
|
|
|
|
|
* Returns: %TRUE if connection is of the given slave @type
|
|
|
|
|
*/
|
|
|
|
|
gboolean
|
|
|
|
|
nm_setting_connection_is_slave_type(NMSettingConnection *setting, const char *type)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), FALSE);
|
|
|
|
|
|
|
|
|
|
return !g_strcmp0(NM_SETTING_CONNECTION_GET_PRIVATE(setting)->slave_type, type);
|
|
|
|
|
}
|
|
|
|
|
|
2019-07-01 10:01:28 +02:00
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_get_wait_device_timeout:
|
|
|
|
|
* @setting: the #NMSettingConnection
|
|
|
|
|
*
|
|
|
|
|
* Returns: the %NM_SETTING_CONNECTION_WAIT_DEVICE_TIMEOUT property with
|
settings: rework wait-device-timeout handling and consider device compatibility
A profile can configure "connection.wait-device-timeout" to indicate
that startup complete is blocked until a suitable device around.
This is useful for NetworkManager-wait-online and initrd mode.
Previously, we looked at NMPlatform whether a link with matching
interface-name was present. That is wrong because it cannot handle
profiles that rely on "ethernet.mac-address" setting or other "match"
settings. Also, the mere presence of the link does not yet mean
that the NMDevice was created and ready. In fact, there is a race here:
NMPlatform indicates that the device is ready (unblocking NMSettings),
but there is no corresponding NMDevice yet which keeps NetworkManager
busy to block startup complete.
Rework this. Now, only check whether there is a compatible device for
the profile.
Since we wait for compatible devices, it works now not only for the
interface name. Note that we do some optimizations so that we don't have
to re-evaluate all profiles (w.r.t. all devices) whenever something on the
device changes: we only care about this when all devices finally become
ready.
Also, we no longer start the timeout for "connection.wait-device-timeout"
when the profile appears. Instead, there is one system-wide start time
(NMSettingsPrivate.startup_complete_start_timestamp_msec). That simplifies
code and makes sense: we start waiting when NetworkManager is starting, not
when the profile gets added. Also, we wait for all profiles to become
ready together.
2020-08-11 15:34:59 +02:00
|
|
|
* the timeout in milliseconds. -1 is the default.
|
2019-07-01 10:01:28 +02:00
|
|
|
*
|
|
|
|
|
* Since: 1.20
|
|
|
|
|
*/
|
|
|
|
|
gint32
|
|
|
|
|
nm_setting_connection_get_wait_device_timeout(NMSettingConnection *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), -1);
|
|
|
|
|
|
|
|
|
|
return NM_SETTING_CONNECTION_GET_PRIVATE(setting)->wait_device_timeout;
|
|
|
|
|
}
|
|
|
|
|
|
2022-05-27 12:36:29 +02:00
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_get_wait_activation_delay:
|
|
|
|
|
* @setting: the #NMSettingConnection
|
|
|
|
|
*
|
|
|
|
|
* Returns: the %NM_SETTING_CONNECTION_WAIT_ACTIVATION_DELAY property with
|
|
|
|
|
* the delay in milliseconds. -1 is the default.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.40
|
|
|
|
|
*/
|
|
|
|
|
gint32
|
|
|
|
|
nm_setting_connection_get_wait_activation_delay(NMSettingConnection *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), -1);
|
|
|
|
|
|
|
|
|
|
return NM_SETTING_CONNECTION_GET_PRIVATE(setting)->wait_activation_delay;
|
|
|
|
|
}
|
|
|
|
|
|
2015-05-06 10:54:35 +02:00
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_get_autoconnect_slaves:
|
|
|
|
|
* @setting: the #NMSettingConnection
|
|
|
|
|
*
|
|
|
|
|
* Returns the #NMSettingConnection:autoconnect-slaves property of the connection.
|
|
|
|
|
*
|
|
|
|
|
* Returns: whether slaves of the connection should be activated together
|
|
|
|
|
* with the connection.
|
|
|
|
|
*
|
Revert "all: change "Since: 1.2" to "Since: 1.0.4"/"Since: 1.0.6" for backported API"
API should be added with "Since:" of the next release on the same branch.
That means, new API on 1.1 branch (development), should be "Since: 1.2"
and new API on 1.0 branch (stable) will be "Since: 1.0.x". Similarly, new
API on master is NM_AVAILABLE_IN_1_2 and will be added with the linker
version libnl_1_2 -- never the versions of minor releases.
It is also strongly advised that for the 1.0 branch, we only add API
that was previously formerly added on master. IOW, that we only do true
backports of API that already exists on master.
API that gets backported, must also be added to master via NM_BACKPORT_SYMBOL().
That gives ABI compatibility and an application that was build against 1.0.x
will work with 1.y.z version (y > 0) without need for recompiling -- provided
that 1.y.z also contains that API.
There is one important caveat: if a major branch (e.g. current master) has a
linker section of backported APIs (e.g. libnm_1_0_6), we must do the minor release
(1.0.6) before the next major release (1.2). The reason is that after the major
release, the linker section (libnm_1_0_6) must not be extended and thus
the minor release (1.0.6) must be already released at that point.
In general, users should avoid using backported API because it limits
the ability to upgrade to arbitrary later versions. But together with the
previous point (that we only backport API to minor releases), a user that
uses backported API can be sure that a 1.y.z version is ABI compatible with
1.0.x, if the 1.y.z release date was after the release date of 1.0.x.
This reverts commit 02a136682c749a0fd27853c0152d36c44635151f.
2015-08-22 00:57:30 +02:00
|
|
|
* Since: 1.2
|
2015-05-06 10:54:35 +02:00
|
|
|
**/
|
|
|
|
|
NMSettingConnectionAutoconnectSlaves
|
|
|
|
|
nm_setting_connection_get_autoconnect_slaves(NMSettingConnection *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting),
|
|
|
|
|
NM_SETTING_CONNECTION_AUTOCONNECT_SLAVES_DEFAULT);
|
|
|
|
|
|
|
|
|
|
return NM_SETTING_CONNECTION_GET_PRIVATE(setting)->autoconnect_slaves;
|
|
|
|
|
}
|
|
|
|
|
|
libnm: verify and normalize "connection.secondaries"
So far, we didn't verify the secondary connections at all.
But these really are supposed to be UUIDs.
As we now also normalize "connection.uuid" to be in a strict
format, the user might have profiles with non-normalized UUIDs.
In that case, the "connection.uuid" would be normalized, but
"connection.secondaries" no longer matches. We can fix that by
also normalizing "connection.secondaries". OK, this is not a very good
reason, because it's unlikely to affect any users in practice ('though
it's easy to reproduce).
A better reason is that the secondary setting really should be well
defined and verified. As we didn't do that so far, we cannot simply
outright reject invalid settings. What this patch does instead, is
silently changing the profile to only contain valid settings.
That has it's own problems, like that the user setting an invalid
value does not get an error nor the desired(?) outcome.
But of all the bad choices, normalizing seems the most sensible
one.
Note that in practice, most client applications don't rely on setting
arbitrary (invalid) "UUIDs". They simply expect to be able to set valid
UUIDs, which they still are. For example, nm-connection-editor presents
a drop down list of VPN profile, and nmcli also resolves connection IDs
to the UUID. That is, clients already have an intimate understanding of
this setting, and don't blindly set arbitrary values. Hence, this
normalization is unlikely to hit users in practice. But what it gives
is the guarantee that a verified connection only contains valid UUIDs.
Now all UUIDs will be normalized, invalid entries removed, and the list
made unique.
2021-06-02 15:15:43 +02:00
|
|
|
GArray *
|
|
|
|
|
_nm_setting_connection_get_secondaries(NMSettingConnection *setting)
|
|
|
|
|
{
|
2022-01-24 17:24:25 +01:00
|
|
|
return NM_SETTING_CONNECTION_GET_PRIVATE(setting)->secondaries.arr;
|
libnm: verify and normalize "connection.secondaries"
So far, we didn't verify the secondary connections at all.
But these really are supposed to be UUIDs.
As we now also normalize "connection.uuid" to be in a strict
format, the user might have profiles with non-normalized UUIDs.
In that case, the "connection.uuid" would be normalized, but
"connection.secondaries" no longer matches. We can fix that by
also normalizing "connection.secondaries". OK, this is not a very good
reason, because it's unlikely to affect any users in practice ('though
it's easy to reproduce).
A better reason is that the secondary setting really should be well
defined and verified. As we didn't do that so far, we cannot simply
outright reject invalid settings. What this patch does instead, is
silently changing the profile to only contain valid settings.
That has it's own problems, like that the user setting an invalid
value does not get an error nor the desired(?) outcome.
But of all the bad choices, normalizing seems the most sensible
one.
Note that in practice, most client applications don't rely on setting
arbitrary (invalid) "UUIDs". They simply expect to be able to set valid
UUIDs, which they still are. For example, nm-connection-editor presents
a drop down list of VPN profile, and nmcli also resolves connection IDs
to the UUID. That is, clients already have an intimate understanding of
this setting, and don't blindly set arbitrary values. Hence, this
normalization is unlikely to hit users in practice. But what it gives
is the guarantee that a verified connection only contains valid UUIDs.
Now all UUIDs will be normalized, invalid entries removed, and the list
made unique.
2021-06-02 15:15:43 +02:00
|
|
|
}
|
|
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_get_num_secondaries:
|
|
|
|
|
* @setting: the #NMSettingConnection
|
|
|
|
|
*
|
|
|
|
|
* Returns: the number of configured secondary connection UUIDs
|
|
|
|
|
**/
|
|
|
|
|
guint32
|
|
|
|
|
nm_setting_connection_get_num_secondaries(NMSettingConnection *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), 0);
|
|
|
|
|
|
2022-01-24 17:24:25 +01:00
|
|
|
return nm_g_array_len(NM_SETTING_CONNECTION_GET_PRIVATE(setting)->secondaries.arr);
|
2014-07-24 08:53:33 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_get_secondary:
|
|
|
|
|
* @setting: the #NMSettingConnection
|
2021-06-02 14:19:23 +02:00
|
|
|
* @idx: the zero-based index of the secondary connection UUID entry.
|
|
|
|
|
* Access one past the length of secondaries is ok and will return
|
|
|
|
|
* %NULL. Otherwise, it is a user error.
|
2014-07-24 08:53:33 -04:00
|
|
|
*
|
2021-06-02 14:19:23 +02:00
|
|
|
* Returns: the secondary connection UUID at index @idx or
|
|
|
|
|
* %NULL if @idx is the number of secondaries.
|
2014-07-24 08:53:33 -04:00
|
|
|
**/
|
|
|
|
|
const char *
|
|
|
|
|
nm_setting_connection_get_secondary(NMSettingConnection *setting, guint32 idx)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), NULL);
|
|
|
|
|
|
2023-10-11 12:34:22 +02:00
|
|
|
return nm_strvarray_get_idxnull_or_greturn(
|
|
|
|
|
NM_SETTING_CONNECTION_GET_PRIVATE(setting)->secondaries.arr,
|
|
|
|
|
idx);
|
2014-07-24 08:53:33 -04:00
|
|
|
}
|
|
|
|
|
|
2020-04-08 07:30:08 +00:00
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_get_mud_url:
|
|
|
|
|
* @setting: the #NMSettingConnection
|
|
|
|
|
*
|
|
|
|
|
* Returns the value contained in the #NMSettingConnection:mud-url
|
|
|
|
|
* property.
|
2020-04-24 09:20:25 +02:00
|
|
|
*
|
|
|
|
|
* Since: 1.26
|
2020-04-08 07:30:08 +00:00
|
|
|
**/
|
|
|
|
|
const char *
|
|
|
|
|
nm_setting_connection_get_mud_url(NMSettingConnection *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), NULL);
|
|
|
|
|
|
|
|
|
|
return NM_SETTING_CONNECTION_GET_PRIVATE(setting)->mud_url;
|
|
|
|
|
}
|
|
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_add_secondary:
|
|
|
|
|
* @setting: the #NMSettingConnection
|
|
|
|
|
* @sec_uuid: the secondary connection UUID to add
|
|
|
|
|
*
|
2018-09-15 07:20:54 -04:00
|
|
|
* Adds a new secondary connection UUID to the setting.
|
2014-07-24 08:53:33 -04:00
|
|
|
*
|
|
|
|
|
* Returns: %TRUE if the secondary connection UUID was added; %FALSE if the UUID
|
|
|
|
|
* was already present
|
|
|
|
|
**/
|
|
|
|
|
gboolean
|
|
|
|
|
nm_setting_connection_add_secondary(NMSettingConnection *setting, const char *sec_uuid)
|
|
|
|
|
{
|
|
|
|
|
NMSettingConnectionPrivate *priv;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), FALSE);
|
2021-06-02 14:00:46 +02:00
|
|
|
g_return_val_if_fail(sec_uuid, FALSE);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
priv = NM_SETTING_CONNECTION_GET_PRIVATE(setting);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2023-10-26 13:37:34 +02:00
|
|
|
if (!nm_strvarray_ensure_and_add_unique(&priv->secondaries.arr, sec_uuid))
|
2021-06-02 14:19:23 +02:00
|
|
|
return FALSE;
|
|
|
|
|
|
2019-01-11 08:28:26 +01:00
|
|
|
_notify(setting, PROP_SECONDARIES);
|
2014-07-24 08:53:33 -04:00
|
|
|
return TRUE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_remove_secondary:
|
|
|
|
|
* @setting: the #NMSettingConnection
|
|
|
|
|
* @idx: index number of the secondary connection UUID
|
|
|
|
|
*
|
2020-07-04 11:37:01 +03:00
|
|
|
* Removes the secondary connection UUID at index @idx.
|
2014-07-24 08:53:33 -04:00
|
|
|
**/
|
|
|
|
|
void
|
|
|
|
|
nm_setting_connection_remove_secondary(NMSettingConnection *setting, guint32 idx)
|
|
|
|
|
{
|
|
|
|
|
NMSettingConnectionPrivate *priv;
|
|
|
|
|
|
|
|
|
|
g_return_if_fail(NM_IS_SETTING_CONNECTION(setting));
|
|
|
|
|
|
|
|
|
|
priv = NM_SETTING_CONNECTION_GET_PRIVATE(setting);
|
|
|
|
|
|
2022-01-24 17:24:25 +01:00
|
|
|
g_return_if_fail(idx < nm_g_array_len(priv->secondaries.arr));
|
2021-06-02 14:19:23 +02:00
|
|
|
|
2023-10-26 13:37:34 +02:00
|
|
|
nm_strvarray_remove_index(priv->secondaries.arr, idx);
|
2019-01-11 08:28:26 +01:00
|
|
|
_notify(setting, PROP_SECONDARIES);
|
2014-07-24 08:53:33 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_remove_secondary_by_value:
|
|
|
|
|
* @setting: the #NMSettingConnection
|
|
|
|
|
* @sec_uuid: the secondary connection UUID to remove
|
|
|
|
|
*
|
2020-07-04 11:37:01 +03:00
|
|
|
* Removes the secondary connection UUID @sec_uuid.
|
2014-07-24 08:53:33 -04:00
|
|
|
*
|
|
|
|
|
* Returns: %TRUE if the secondary connection UUID was found and removed; %FALSE if it was not.
|
|
|
|
|
**/
|
|
|
|
|
gboolean
|
|
|
|
|
nm_setting_connection_remove_secondary_by_value(NMSettingConnection *setting, const char *sec_uuid)
|
|
|
|
|
{
|
|
|
|
|
NMSettingConnectionPrivate *priv;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), FALSE);
|
2021-06-02 14:00:46 +02:00
|
|
|
g_return_val_if_fail(sec_uuid, FALSE);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
priv = NM_SETTING_CONNECTION_GET_PRIVATE(setting);
|
2021-06-02 14:19:23 +02:00
|
|
|
|
2023-10-26 13:37:34 +02:00
|
|
|
if (!nm_strvarray_remove_first(priv->secondaries.arr, sec_uuid))
|
|
|
|
|
return FALSE;
|
|
|
|
|
|
|
|
|
|
_notify(setting, PROP_SECONDARIES);
|
|
|
|
|
return TRUE;
|
2014-07-24 08:53:33 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_get_gateway_ping_timeout:
|
|
|
|
|
* @setting: the #NMSettingConnection
|
|
|
|
|
*
|
|
|
|
|
* Returns: the value contained in the #NMSettingConnection:gateway-ping-timeout
|
|
|
|
|
* property.
|
|
|
|
|
**/
|
|
|
|
|
guint32
|
|
|
|
|
nm_setting_connection_get_gateway_ping_timeout(NMSettingConnection *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), 0);
|
|
|
|
|
|
|
|
|
|
return NM_SETTING_CONNECTION_GET_PRIVATE(setting)->gateway_ping_timeout;
|
|
|
|
|
}
|
|
|
|
|
|
2015-04-27 17:45:53 +02:00
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_get_metered:
|
|
|
|
|
* @setting: the #NMSettingConnection
|
|
|
|
|
*
|
|
|
|
|
* Returns: the #NMSettingConnection:metered property of the setting.
|
|
|
|
|
*
|
Revert "all: change "Since: 1.2" to "Since: 1.0.4"/"Since: 1.0.6" for backported API"
API should be added with "Since:" of the next release on the same branch.
That means, new API on 1.1 branch (development), should be "Since: 1.2"
and new API on 1.0 branch (stable) will be "Since: 1.0.x". Similarly, new
API on master is NM_AVAILABLE_IN_1_2 and will be added with the linker
version libnl_1_2 -- never the versions of minor releases.
It is also strongly advised that for the 1.0 branch, we only add API
that was previously formerly added on master. IOW, that we only do true
backports of API that already exists on master.
API that gets backported, must also be added to master via NM_BACKPORT_SYMBOL().
That gives ABI compatibility and an application that was build against 1.0.x
will work with 1.y.z version (y > 0) without need for recompiling -- provided
that 1.y.z also contains that API.
There is one important caveat: if a major branch (e.g. current master) has a
linker section of backported APIs (e.g. libnm_1_0_6), we must do the minor release
(1.0.6) before the next major release (1.2). The reason is that after the major
release, the linker section (libnm_1_0_6) must not be extended and thus
the minor release (1.0.6) must be already released at that point.
In general, users should avoid using backported API because it limits
the ability to upgrade to arbitrary later versions. But together with the
previous point (that we only backport API to minor releases), a user that
uses backported API can be sure that a 1.y.z version is ABI compatible with
1.0.x, if the 1.y.z release date was after the release date of 1.0.x.
This reverts commit 02a136682c749a0fd27853c0152d36c44635151f.
2015-08-22 00:57:30 +02:00
|
|
|
* Since: 1.2
|
2015-04-27 17:45:53 +02:00
|
|
|
**/
|
|
|
|
|
NMMetered
|
|
|
|
|
nm_setting_connection_get_metered(NMSettingConnection *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), NM_METERED_UNKNOWN);
|
|
|
|
|
|
|
|
|
|
return NM_SETTING_CONNECTION_GET_PRIVATE(setting)->metered;
|
|
|
|
|
}
|
|
|
|
|
|
2015-10-07 11:48:30 +02:00
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_get_lldp:
|
|
|
|
|
* @setting: the #NMSettingConnection
|
|
|
|
|
*
|
|
|
|
|
* Returns the #NMSettingConnection:lldp property of the connection.
|
|
|
|
|
*
|
|
|
|
|
* Returns: a %NMSettingConnectionLldp which indicates whether LLDP must be
|
|
|
|
|
* enabled for the connection.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.2
|
|
|
|
|
**/
|
|
|
|
|
NMSettingConnectionLldp
|
|
|
|
|
nm_setting_connection_get_lldp(NMSettingConnection *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), NM_SETTING_CONNECTION_LLDP_DEFAULT);
|
|
|
|
|
|
|
|
|
|
return NM_SETTING_CONNECTION_GET_PRIVATE(setting)->lldp;
|
|
|
|
|
}
|
2015-07-21 19:02:12 +02:00
|
|
|
|
2017-11-10 14:49:27 +02:00
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_get_mdns:
|
|
|
|
|
* @setting: the #NMSettingConnection
|
|
|
|
|
*
|
|
|
|
|
* Returns: the #NMSettingConnection:mdns property of the setting.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
|
|
|
|
NMSettingConnectionMdns
|
|
|
|
|
nm_setting_connection_get_mdns(NMSettingConnection *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), NM_SETTING_CONNECTION_MDNS_DEFAULT);
|
|
|
|
|
|
|
|
|
|
return NM_SETTING_CONNECTION_GET_PRIVATE(setting)->mdns;
|
|
|
|
|
}
|
|
|
|
|
|
2018-08-31 10:48:18 +02:00
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_get_llmnr:
|
|
|
|
|
* @setting: the #NMSettingConnection
|
|
|
|
|
*
|
|
|
|
|
* Returns: the #NMSettingConnection:llmnr property of the setting.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.14
|
|
|
|
|
**/
|
|
|
|
|
NMSettingConnectionLlmnr
|
|
|
|
|
nm_setting_connection_get_llmnr(NMSettingConnection *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), NM_SETTING_CONNECTION_LLMNR_DEFAULT);
|
|
|
|
|
|
|
|
|
|
return NM_SETTING_CONNECTION_GET_PRIVATE(setting)->llmnr;
|
|
|
|
|
}
|
|
|
|
|
|
2021-10-03 19:16:01 +02:00
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_get_dns_over_tls:
|
|
|
|
|
* @setting: the #NMSettingConnection
|
|
|
|
|
*
|
|
|
|
|
* Returns: the #NMSettingConnection:dns-over-tls property of the setting.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.34
|
|
|
|
|
**/
|
|
|
|
|
NMSettingConnectionDnsOverTls
|
|
|
|
|
nm_setting_connection_get_dns_over_tls(NMSettingConnection *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting),
|
|
|
|
|
NM_SETTING_CONNECTION_DNS_OVER_TLS_DEFAULT);
|
|
|
|
|
|
|
|
|
|
return NM_SETTING_CONNECTION_GET_PRIVATE(setting)->dns_over_tls;
|
|
|
|
|
}
|
|
|
|
|
|
2022-07-18 21:24:09 +02:00
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_get_mptcp_flags:
|
|
|
|
|
* @setting: the #NMSettingConnection
|
|
|
|
|
*
|
|
|
|
|
* Returns: the #NMSettingConnection:mptcp-flags property of the setting.
|
|
|
|
|
*
|
2022-11-07 20:29:12 +01:00
|
|
|
* Since: 1.42
|
2022-07-18 21:24:09 +02:00
|
|
|
**/
|
|
|
|
|
NMMptcpFlags
|
|
|
|
|
nm_setting_connection_get_mptcp_flags(NMSettingConnection *setting)
|
|
|
|
|
{
|
|
|
|
|
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), NM_MPTCP_FLAGS_NONE);
|
|
|
|
|
|
|
|
|
|
return NM_SETTING_CONNECTION_GET_PRIVATE(setting)->mptcp_flags;
|
|
|
|
|
}
|
|
|
|
|
|
2014-07-08 18:36:02 +02:00
|
|
|
static void
|
|
|
|
|
_set_error_missing_base_setting(GError **error, const char *type)
|
|
|
|
|
{
|
|
|
|
|
g_set_error(error,
|
libnm-core: merge NMSetting*Error into NMConnectionError
Each setting type was defining its own error type, but most of them
had exactly the same three errors ("unknown", "missing property", and
"invalid property"), and none of the other values was of much use
programmatically anyway.
So, this commit merges NMSettingError, NMSettingAdslError, etc, all
into NMConnectionError. (The reason for merging into NMConnectionError
rather than NMSettingError is that we also already have
"NMSettingsError", for errors related to the settings service, so
"NMConnectionError" is a less-confusable name for settings/connection
errors than "NMSettingError".)
Also, make sure that all of the affected error messages are localized,
and (where appropriate) prefix them with the relevant property name.
Renamed error codes:
NM_SETTING_ERROR_PROPERTY_NOT_FOUND -> NM_CONNECTION_ERROR_PROPERTY_NOT_FOUND
NM_SETTING_ERROR_PROPERTY_NOT_SECRET -> NM_CONNECTION_ERROR_PROPERTY_NOT_SECRET
Remapped error codes:
NM_SETTING_*_ERROR_MISSING_PROPERTY -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_*_ERROR_INVALID_PROPERTY -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_ERROR_PROPERTY_TYPE_MISMATCH -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BLUETOOTH_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_INVALID_SETTING
NM_SETTING_BOND_ERROR_INVALID_OPTION -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BOND_ERROR_MISSING_OPTION -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_CONNECTION_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_CONNECTION_ERROR_SLAVE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_IP4_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_IP6_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_VLAN_ERROR_INVALID_PARENT -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_MISSING_802_1X_SETTING -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_802_1X -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_USERNAME -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_SHARED_KEY_REQUIRES_WEP -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_ERROR_CHANNEL_REQUIRES_BAND -> NM_CONNECTION_ERROR_MISSING_PROPERTY
Dropped error codes (were previously defined but unused):
NM_SETTING_CDMA_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_CONNECTION_ERROR_IP_CONFIG_NOT_ALLOWED
NM_SETTING_GSM_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_PPP_ERROR_REQUIRE_MPPE_NOT_ALLOWED
NM_SETTING_PPPOE_ERROR_MISSING_PPP_SETTING
NM_SETTING_SERIAL_ERROR_MISSING_PPP_SETTING
NM_SETTING_WIRELESS_ERROR_MISSING_SECURITY_SETTING
2014-10-20 13:52:23 -04:00
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_MISSING_SETTING,
|
|
|
|
|
_("setting required for connection of type '%s'"),
|
2014-07-08 18:36:02 +02:00
|
|
|
type);
|
libnm-core: merge NMSetting*Error into NMConnectionError
Each setting type was defining its own error type, but most of them
had exactly the same three errors ("unknown", "missing property", and
"invalid property"), and none of the other values was of much use
programmatically anyway.
So, this commit merges NMSettingError, NMSettingAdslError, etc, all
into NMConnectionError. (The reason for merging into NMConnectionError
rather than NMSettingError is that we also already have
"NMSettingsError", for errors related to the settings service, so
"NMConnectionError" is a less-confusable name for settings/connection
errors than "NMSettingError".)
Also, make sure that all of the affected error messages are localized,
and (where appropriate) prefix them with the relevant property name.
Renamed error codes:
NM_SETTING_ERROR_PROPERTY_NOT_FOUND -> NM_CONNECTION_ERROR_PROPERTY_NOT_FOUND
NM_SETTING_ERROR_PROPERTY_NOT_SECRET -> NM_CONNECTION_ERROR_PROPERTY_NOT_SECRET
Remapped error codes:
NM_SETTING_*_ERROR_MISSING_PROPERTY -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_*_ERROR_INVALID_PROPERTY -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_ERROR_PROPERTY_TYPE_MISMATCH -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BLUETOOTH_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_INVALID_SETTING
NM_SETTING_BOND_ERROR_INVALID_OPTION -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BOND_ERROR_MISSING_OPTION -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_CONNECTION_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_CONNECTION_ERROR_SLAVE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_IP4_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_IP6_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_VLAN_ERROR_INVALID_PARENT -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_MISSING_802_1X_SETTING -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_802_1X -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_USERNAME -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_SHARED_KEY_REQUIRES_WEP -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_ERROR_CHANNEL_REQUIRES_BAND -> NM_CONNECTION_ERROR_MISSING_PROPERTY
Dropped error codes (were previously defined but unused):
NM_SETTING_CDMA_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_CONNECTION_ERROR_IP_CONFIG_NOT_ALLOWED
NM_SETTING_GSM_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_PPP_ERROR_REQUIRE_MPPE_NOT_ALLOWED
NM_SETTING_PPPOE_ERROR_MISSING_PPP_SETTING
NM_SETTING_SERIAL_ERROR_MISSING_PPP_SETTING
NM_SETTING_WIRELESS_ERROR_MISSING_SECURITY_SETTING
2014-10-20 13:52:23 -04:00
|
|
|
g_prefix_error(error, "%s: ", type);
|
2014-07-08 18:36:02 +02:00
|
|
|
}
|
2014-07-24 08:53:33 -04:00
|
|
|
|
2020-12-09 10:41:05 +01:00
|
|
|
gboolean
|
|
|
|
|
_nm_connection_detect_slave_type_full(NMSettingConnection *s_con,
|
2021-11-09 13:28:54 +01:00
|
|
|
NMConnection *connection,
|
|
|
|
|
const char **out_slave_type,
|
|
|
|
|
const char **out_normerr_slave_setting_type,
|
|
|
|
|
const char **out_normerr_missing_slave_type,
|
|
|
|
|
const char **out_normerr_missing_slave_type_port,
|
|
|
|
|
GError **error)
|
2014-07-24 08:53:33 -04:00
|
|
|
{
|
2020-12-09 10:41:05 +01:00
|
|
|
NMSettingConnectionPrivate *priv = NM_SETTING_CONNECTION_GET_PRIVATE(s_con);
|
2014-07-24 08:53:33 -04:00
|
|
|
gboolean is_slave;
|
2021-11-09 13:28:54 +01:00
|
|
|
const char *slave_setting_type;
|
|
|
|
|
const char *slave_type;
|
|
|
|
|
const char *normerr_slave_setting_type = NULL;
|
|
|
|
|
const char *normerr_missing_slave_type = NULL;
|
|
|
|
|
const char *normerr_missing_slave_type_port = NULL;
|
2020-12-09 10:41:05 +01:00
|
|
|
|
|
|
|
|
is_slave = FALSE;
|
|
|
|
|
slave_setting_type = NULL;
|
|
|
|
|
slave_type = priv->slave_type;
|
|
|
|
|
if (slave_type) {
|
|
|
|
|
is_slave = _nm_setting_slave_type_is_valid(slave_type, &slave_setting_type);
|
|
|
|
|
if (!is_slave) {
|
|
|
|
|
g_set_error(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_INVALID_PROPERTY,
|
|
|
|
|
_("Unknown slave type '%s'"),
|
|
|
|
|
slave_type);
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_CONNECTION_SETTING_NAME,
|
|
|
|
|
NM_SETTING_CONNECTION_SLAVE_TYPE);
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (is_slave) {
|
|
|
|
|
if (!priv->master) {
|
|
|
|
|
g_set_error(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_MISSING_PROPERTY,
|
|
|
|
|
_("Slave connections need a valid '%s' property"),
|
|
|
|
|
NM_SETTING_CONNECTION_MASTER);
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_CONNECTION_SETTING_NAME,
|
|
|
|
|
NM_SETTING_CONNECTION_MASTER);
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
if (slave_setting_type && connection
|
|
|
|
|
&& !nm_connection_get_setting_by_name(connection, slave_setting_type))
|
|
|
|
|
normerr_slave_setting_type = slave_setting_type;
|
|
|
|
|
} else {
|
|
|
|
|
nm_assert(!slave_type);
|
|
|
|
|
if (priv->master) {
|
|
|
|
|
NMSetting *s_port;
|
|
|
|
|
|
|
|
|
|
if (connection
|
|
|
|
|
&& (slave_type = _nm_connection_detect_slave_type(connection, &s_port))) {
|
|
|
|
|
normerr_missing_slave_type = slave_type;
|
|
|
|
|
normerr_missing_slave_type_port = nm_setting_get_name(s_port);
|
|
|
|
|
} else {
|
|
|
|
|
g_set_error(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_MISSING_PROPERTY,
|
|
|
|
|
_("Cannot set '%s' without '%s'"),
|
|
|
|
|
NM_SETTING_CONNECTION_MASTER,
|
|
|
|
|
NM_SETTING_CONNECTION_SLAVE_TYPE);
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_CONNECTION_SETTING_NAME,
|
|
|
|
|
NM_SETTING_CONNECTION_SLAVE_TYPE);
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
NM_SET_OUT(out_slave_type, slave_type);
|
|
|
|
|
NM_SET_OUT(out_normerr_slave_setting_type, normerr_slave_setting_type);
|
|
|
|
|
NM_SET_OUT(out_normerr_missing_slave_type, normerr_missing_slave_type);
|
|
|
|
|
NM_SET_OUT(out_normerr_missing_slave_type_port, normerr_missing_slave_type_port);
|
|
|
|
|
return TRUE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static gboolean
|
|
|
|
|
verify(NMSetting *setting, NMConnection *connection, GError **error)
|
|
|
|
|
{
|
2021-11-09 13:28:54 +01:00
|
|
|
NMSettingConnection *self = NM_SETTING_CONNECTION(setting);
|
2020-12-09 10:41:05 +01:00
|
|
|
NMSettingConnectionPrivate *priv = NM_SETTING_CONNECTION_GET_PRIVATE(self);
|
2021-11-09 13:28:54 +01:00
|
|
|
NMSetting *normerr_base_type = NULL;
|
|
|
|
|
const char *type;
|
|
|
|
|
const char *slave_type;
|
|
|
|
|
const char *normerr_slave_setting_type = NULL;
|
|
|
|
|
const char *normerr_missing_slave_type = NULL;
|
|
|
|
|
const char *normerr_missing_slave_type_port = NULL;
|
2014-07-08 18:36:02 +02:00
|
|
|
gboolean normerr_base_setting = FALSE;
|
2021-05-02 22:42:51 +02:00
|
|
|
gboolean uuid_was_normalized = FALSE;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
if (!priv->id) {
|
|
|
|
|
g_set_error_literal(error,
|
libnm-core: merge NMSetting*Error into NMConnectionError
Each setting type was defining its own error type, but most of them
had exactly the same three errors ("unknown", "missing property", and
"invalid property"), and none of the other values was of much use
programmatically anyway.
So, this commit merges NMSettingError, NMSettingAdslError, etc, all
into NMConnectionError. (The reason for merging into NMConnectionError
rather than NMSettingError is that we also already have
"NMSettingsError", for errors related to the settings service, so
"NMConnectionError" is a less-confusable name for settings/connection
errors than "NMSettingError".)
Also, make sure that all of the affected error messages are localized,
and (where appropriate) prefix them with the relevant property name.
Renamed error codes:
NM_SETTING_ERROR_PROPERTY_NOT_FOUND -> NM_CONNECTION_ERROR_PROPERTY_NOT_FOUND
NM_SETTING_ERROR_PROPERTY_NOT_SECRET -> NM_CONNECTION_ERROR_PROPERTY_NOT_SECRET
Remapped error codes:
NM_SETTING_*_ERROR_MISSING_PROPERTY -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_*_ERROR_INVALID_PROPERTY -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_ERROR_PROPERTY_TYPE_MISMATCH -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BLUETOOTH_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_INVALID_SETTING
NM_SETTING_BOND_ERROR_INVALID_OPTION -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BOND_ERROR_MISSING_OPTION -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_CONNECTION_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_CONNECTION_ERROR_SLAVE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_IP4_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_IP6_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_VLAN_ERROR_INVALID_PARENT -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_MISSING_802_1X_SETTING -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_802_1X -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_USERNAME -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_SHARED_KEY_REQUIRES_WEP -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_ERROR_CHANNEL_REQUIRES_BAND -> NM_CONNECTION_ERROR_MISSING_PROPERTY
Dropped error codes (were previously defined but unused):
NM_SETTING_CDMA_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_CONNECTION_ERROR_IP_CONFIG_NOT_ALLOWED
NM_SETTING_GSM_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_PPP_ERROR_REQUIRE_MPPE_NOT_ALLOWED
NM_SETTING_PPPOE_ERROR_MISSING_PPP_SETTING
NM_SETTING_SERIAL_ERROR_MISSING_PPP_SETTING
NM_SETTING_WIRELESS_ERROR_MISSING_SECURITY_SETTING
2014-10-20 13:52:23 -04:00
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_MISSING_PROPERTY,
|
2014-07-24 08:53:33 -04:00
|
|
|
_("property is missing"));
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_CONNECTION_SETTING_NAME,
|
|
|
|
|
NM_SETTING_CONNECTION_ID);
|
|
|
|
|
return FALSE;
|
2014-07-08 17:22:43 +02:00
|
|
|
} else if (!priv->id[0]) {
|
2014-07-24 08:53:33 -04:00
|
|
|
g_set_error_literal(error,
|
libnm-core: merge NMSetting*Error into NMConnectionError
Each setting type was defining its own error type, but most of them
had exactly the same three errors ("unknown", "missing property", and
"invalid property"), and none of the other values was of much use
programmatically anyway.
So, this commit merges NMSettingError, NMSettingAdslError, etc, all
into NMConnectionError. (The reason for merging into NMConnectionError
rather than NMSettingError is that we also already have
"NMSettingsError", for errors related to the settings service, so
"NMConnectionError" is a less-confusable name for settings/connection
errors than "NMSettingError".)
Also, make sure that all of the affected error messages are localized,
and (where appropriate) prefix them with the relevant property name.
Renamed error codes:
NM_SETTING_ERROR_PROPERTY_NOT_FOUND -> NM_CONNECTION_ERROR_PROPERTY_NOT_FOUND
NM_SETTING_ERROR_PROPERTY_NOT_SECRET -> NM_CONNECTION_ERROR_PROPERTY_NOT_SECRET
Remapped error codes:
NM_SETTING_*_ERROR_MISSING_PROPERTY -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_*_ERROR_INVALID_PROPERTY -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_ERROR_PROPERTY_TYPE_MISMATCH -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BLUETOOTH_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_INVALID_SETTING
NM_SETTING_BOND_ERROR_INVALID_OPTION -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BOND_ERROR_MISSING_OPTION -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_CONNECTION_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_CONNECTION_ERROR_SLAVE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_IP4_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_IP6_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_VLAN_ERROR_INVALID_PARENT -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_MISSING_802_1X_SETTING -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_802_1X -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_USERNAME -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_SHARED_KEY_REQUIRES_WEP -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_ERROR_CHANNEL_REQUIRES_BAND -> NM_CONNECTION_ERROR_MISSING_PROPERTY
Dropped error codes (were previously defined but unused):
NM_SETTING_CDMA_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_CONNECTION_ERROR_IP_CONFIG_NOT_ALLOWED
NM_SETTING_GSM_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_PPP_ERROR_REQUIRE_MPPE_NOT_ALLOWED
NM_SETTING_PPPOE_ERROR_MISSING_PPP_SETTING
NM_SETTING_SERIAL_ERROR_MISSING_PPP_SETTING
NM_SETTING_WIRELESS_ERROR_MISSING_SECURITY_SETTING
2014-10-20 13:52:23 -04:00
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_INVALID_PROPERTY,
|
2014-07-24 08:53:33 -04:00
|
|
|
_("property is empty"));
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_CONNECTION_SETTING_NAME,
|
|
|
|
|
NM_SETTING_CONNECTION_ID);
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2021-05-02 22:42:51 +02:00
|
|
|
if (priv->uuid && !nm_uuid_is_valid_nm(priv->uuid, &uuid_was_normalized, NULL)) {
|
2014-07-24 08:53:33 -04:00
|
|
|
g_set_error(error,
|
libnm-core: merge NMSetting*Error into NMConnectionError
Each setting type was defining its own error type, but most of them
had exactly the same three errors ("unknown", "missing property", and
"invalid property"), and none of the other values was of much use
programmatically anyway.
So, this commit merges NMSettingError, NMSettingAdslError, etc, all
into NMConnectionError. (The reason for merging into NMConnectionError
rather than NMSettingError is that we also already have
"NMSettingsError", for errors related to the settings service, so
"NMConnectionError" is a less-confusable name for settings/connection
errors than "NMSettingError".)
Also, make sure that all of the affected error messages are localized,
and (where appropriate) prefix them with the relevant property name.
Renamed error codes:
NM_SETTING_ERROR_PROPERTY_NOT_FOUND -> NM_CONNECTION_ERROR_PROPERTY_NOT_FOUND
NM_SETTING_ERROR_PROPERTY_NOT_SECRET -> NM_CONNECTION_ERROR_PROPERTY_NOT_SECRET
Remapped error codes:
NM_SETTING_*_ERROR_MISSING_PROPERTY -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_*_ERROR_INVALID_PROPERTY -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_ERROR_PROPERTY_TYPE_MISMATCH -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BLUETOOTH_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_INVALID_SETTING
NM_SETTING_BOND_ERROR_INVALID_OPTION -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BOND_ERROR_MISSING_OPTION -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_CONNECTION_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_CONNECTION_ERROR_SLAVE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_IP4_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_IP6_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_VLAN_ERROR_INVALID_PARENT -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_MISSING_802_1X_SETTING -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_802_1X -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_USERNAME -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_SHARED_KEY_REQUIRES_WEP -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_ERROR_CHANNEL_REQUIRES_BAND -> NM_CONNECTION_ERROR_MISSING_PROPERTY
Dropped error codes (were previously defined but unused):
NM_SETTING_CDMA_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_CONNECTION_ERROR_IP_CONFIG_NOT_ALLOWED
NM_SETTING_GSM_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_PPP_ERROR_REQUIRE_MPPE_NOT_ALLOWED
NM_SETTING_PPPOE_ERROR_MISSING_PPP_SETTING
NM_SETTING_SERIAL_ERROR_MISSING_PPP_SETTING
NM_SETTING_WIRELESS_ERROR_MISSING_SECURITY_SETTING
2014-10-20 13:52:23 -04:00
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_INVALID_PROPERTY,
|
2014-07-24 08:53:33 -04:00
|
|
|
_("'%s' is not a valid UUID"),
|
|
|
|
|
priv->uuid);
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_CONNECTION_SETTING_NAME,
|
|
|
|
|
NM_SETTING_CONNECTION_UUID);
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2017-10-27 14:30:18 +02:00
|
|
|
type = priv->type;
|
|
|
|
|
if (!type) {
|
|
|
|
|
if (!connection
|
|
|
|
|
|| !(normerr_base_type = _nm_connection_find_base_type_setting(connection))) {
|
2014-07-08 18:36:02 +02:00
|
|
|
g_set_error_literal(error,
|
libnm-core: merge NMSetting*Error into NMConnectionError
Each setting type was defining its own error type, but most of them
had exactly the same three errors ("unknown", "missing property", and
"invalid property"), and none of the other values was of much use
programmatically anyway.
So, this commit merges NMSettingError, NMSettingAdslError, etc, all
into NMConnectionError. (The reason for merging into NMConnectionError
rather than NMSettingError is that we also already have
"NMSettingsError", for errors related to the settings service, so
"NMConnectionError" is a less-confusable name for settings/connection
errors than "NMSettingError".)
Also, make sure that all of the affected error messages are localized,
and (where appropriate) prefix them with the relevant property name.
Renamed error codes:
NM_SETTING_ERROR_PROPERTY_NOT_FOUND -> NM_CONNECTION_ERROR_PROPERTY_NOT_FOUND
NM_SETTING_ERROR_PROPERTY_NOT_SECRET -> NM_CONNECTION_ERROR_PROPERTY_NOT_SECRET
Remapped error codes:
NM_SETTING_*_ERROR_MISSING_PROPERTY -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_*_ERROR_INVALID_PROPERTY -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_ERROR_PROPERTY_TYPE_MISMATCH -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BLUETOOTH_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_INVALID_SETTING
NM_SETTING_BOND_ERROR_INVALID_OPTION -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BOND_ERROR_MISSING_OPTION -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_CONNECTION_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_CONNECTION_ERROR_SLAVE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_IP4_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_IP6_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_VLAN_ERROR_INVALID_PARENT -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_MISSING_802_1X_SETTING -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_802_1X -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_USERNAME -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_SHARED_KEY_REQUIRES_WEP -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_ERROR_CHANNEL_REQUIRES_BAND -> NM_CONNECTION_ERROR_MISSING_PROPERTY
Dropped error codes (were previously defined but unused):
NM_SETTING_CDMA_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_CONNECTION_ERROR_IP_CONFIG_NOT_ALLOWED
NM_SETTING_GSM_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_PPP_ERROR_REQUIRE_MPPE_NOT_ALLOWED
NM_SETTING_PPPOE_ERROR_MISSING_PPP_SETTING
NM_SETTING_SERIAL_ERROR_MISSING_PPP_SETTING
NM_SETTING_WIRELESS_ERROR_MISSING_SECURITY_SETTING
2014-10-20 13:52:23 -04:00
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_MISSING_PROPERTY,
|
2014-07-08 18:36:02 +02:00
|
|
|
_("property is missing"));
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_CONNECTION_SETTING_NAME,
|
|
|
|
|
NM_SETTING_CONNECTION_TYPE);
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
2017-10-27 14:30:18 +02:00
|
|
|
type = nm_setting_get_name(normerr_base_type);
|
2014-07-08 17:22:43 +02:00
|
|
|
} else {
|
|
|
|
|
GType base_type;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2017-10-27 14:30:18 +02:00
|
|
|
if (!type[0]) {
|
2014-07-08 17:22:43 +02:00
|
|
|
g_set_error_literal(error,
|
libnm-core: merge NMSetting*Error into NMConnectionError
Each setting type was defining its own error type, but most of them
had exactly the same three errors ("unknown", "missing property", and
"invalid property"), and none of the other values was of much use
programmatically anyway.
So, this commit merges NMSettingError, NMSettingAdslError, etc, all
into NMConnectionError. (The reason for merging into NMConnectionError
rather than NMSettingError is that we also already have
"NMSettingsError", for errors related to the settings service, so
"NMConnectionError" is a less-confusable name for settings/connection
errors than "NMSettingError".)
Also, make sure that all of the affected error messages are localized,
and (where appropriate) prefix them with the relevant property name.
Renamed error codes:
NM_SETTING_ERROR_PROPERTY_NOT_FOUND -> NM_CONNECTION_ERROR_PROPERTY_NOT_FOUND
NM_SETTING_ERROR_PROPERTY_NOT_SECRET -> NM_CONNECTION_ERROR_PROPERTY_NOT_SECRET
Remapped error codes:
NM_SETTING_*_ERROR_MISSING_PROPERTY -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_*_ERROR_INVALID_PROPERTY -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_ERROR_PROPERTY_TYPE_MISMATCH -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BLUETOOTH_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_INVALID_SETTING
NM_SETTING_BOND_ERROR_INVALID_OPTION -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BOND_ERROR_MISSING_OPTION -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_CONNECTION_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_CONNECTION_ERROR_SLAVE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_IP4_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_IP6_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_VLAN_ERROR_INVALID_PARENT -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_MISSING_802_1X_SETTING -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_802_1X -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_USERNAME -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_SHARED_KEY_REQUIRES_WEP -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_ERROR_CHANNEL_REQUIRES_BAND -> NM_CONNECTION_ERROR_MISSING_PROPERTY
Dropped error codes (were previously defined but unused):
NM_SETTING_CDMA_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_CONNECTION_ERROR_IP_CONFIG_NOT_ALLOWED
NM_SETTING_GSM_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_PPP_ERROR_REQUIRE_MPPE_NOT_ALLOWED
NM_SETTING_PPPOE_ERROR_MISSING_PPP_SETTING
NM_SETTING_SERIAL_ERROR_MISSING_PPP_SETTING
NM_SETTING_WIRELESS_ERROR_MISSING_SECURITY_SETTING
2014-10-20 13:52:23 -04:00
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_INVALID_PROPERTY,
|
2014-07-08 17:22:43 +02:00
|
|
|
_("property is empty"));
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_CONNECTION_SETTING_NAME,
|
|
|
|
|
NM_SETTING_CONNECTION_TYPE);
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2017-10-27 14:30:18 +02:00
|
|
|
base_type = nm_setting_lookup_type(type);
|
2017-06-01 13:43:52 +02:00
|
|
|
if (base_type == G_TYPE_INVALID
|
|
|
|
|
|| _nm_setting_type_get_base_type_priority(base_type) == NM_SETTING_PRIORITY_INVALID) {
|
2014-07-03 19:49:52 +02:00
|
|
|
g_set_error(error,
|
libnm-core: merge NMSetting*Error into NMConnectionError
Each setting type was defining its own error type, but most of them
had exactly the same three errors ("unknown", "missing property", and
"invalid property"), and none of the other values was of much use
programmatically anyway.
So, this commit merges NMSettingError, NMSettingAdslError, etc, all
into NMConnectionError. (The reason for merging into NMConnectionError
rather than NMSettingError is that we also already have
"NMSettingsError", for errors related to the settings service, so
"NMConnectionError" is a less-confusable name for settings/connection
errors than "NMSettingError".)
Also, make sure that all of the affected error messages are localized,
and (where appropriate) prefix them with the relevant property name.
Renamed error codes:
NM_SETTING_ERROR_PROPERTY_NOT_FOUND -> NM_CONNECTION_ERROR_PROPERTY_NOT_FOUND
NM_SETTING_ERROR_PROPERTY_NOT_SECRET -> NM_CONNECTION_ERROR_PROPERTY_NOT_SECRET
Remapped error codes:
NM_SETTING_*_ERROR_MISSING_PROPERTY -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_*_ERROR_INVALID_PROPERTY -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_ERROR_PROPERTY_TYPE_MISMATCH -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BLUETOOTH_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_INVALID_SETTING
NM_SETTING_BOND_ERROR_INVALID_OPTION -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BOND_ERROR_MISSING_OPTION -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_CONNECTION_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_CONNECTION_ERROR_SLAVE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_IP4_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_IP6_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_VLAN_ERROR_INVALID_PARENT -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_MISSING_802_1X_SETTING -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_802_1X -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_USERNAME -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_SHARED_KEY_REQUIRES_WEP -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_ERROR_CHANNEL_REQUIRES_BAND -> NM_CONNECTION_ERROR_MISSING_PROPERTY
Dropped error codes (were previously defined but unused):
NM_SETTING_CDMA_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_CONNECTION_ERROR_IP_CONFIG_NOT_ALLOWED
NM_SETTING_GSM_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_PPP_ERROR_REQUIRE_MPPE_NOT_ALLOWED
NM_SETTING_PPPOE_ERROR_MISSING_PPP_SETTING
NM_SETTING_SERIAL_ERROR_MISSING_PPP_SETTING
NM_SETTING_WIRELESS_ERROR_MISSING_SECURITY_SETTING
2014-10-20 13:52:23 -04:00
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_INVALID_PROPERTY,
|
2014-07-08 17:22:43 +02:00
|
|
|
_("connection type '%s' is not valid"),
|
2017-10-27 14:30:18 +02:00
|
|
|
type);
|
2014-07-03 19:49:52 +02:00
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_CONNECTION_SETTING_NAME,
|
|
|
|
|
NM_SETTING_CONNECTION_TYPE);
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-08 17:22:43 +02:00
|
|
|
/* Make sure the corresponding 'type' item is present */
|
2017-10-27 14:30:18 +02:00
|
|
|
if (connection && !nm_connection_get_setting_by_name(connection, type)) {
|
2021-11-09 13:28:54 +01:00
|
|
|
NMSetting *s_base;
|
2014-10-21 22:30:31 -04:00
|
|
|
NMConnection *connection2;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-08 18:36:02 +02:00
|
|
|
s_base = g_object_new(base_type, NULL);
|
2014-10-21 22:30:31 -04:00
|
|
|
connection2 = nm_simple_connection_new_clone(connection);
|
|
|
|
|
nm_connection_add_setting(connection2, s_base);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-10-21 22:30:31 -04:00
|
|
|
normerr_base_setting = nm_setting_verify(s_base, connection2, NULL);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-10-21 22:30:31 -04:00
|
|
|
g_object_unref(connection2);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-08 18:36:02 +02:00
|
|
|
if (!normerr_base_setting) {
|
2017-10-27 14:30:18 +02:00
|
|
|
_set_error_missing_base_setting(error, type);
|
2014-07-08 18:36:02 +02:00
|
|
|
return FALSE;
|
2014-07-24 08:53:33 -04:00
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-02-06 17:17:49 +01:00
|
|
|
if (priv->interface_name) {
|
2021-11-09 13:28:54 +01:00
|
|
|
GError *tmp_error = NULL;
|
2020-02-18 14:00:10 +01:00
|
|
|
NMUtilsIfaceType iface_type;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-02-06 17:17:49 +01:00
|
|
|
if (NM_IN_STRSET(type,
|
|
|
|
|
NM_SETTING_OVS_BRIDGE_SETTING_NAME,
|
2020-02-18 14:00:10 +01:00
|
|
|
NM_SETTING_OVS_PORT_SETTING_NAME))
|
|
|
|
|
iface_type = NMU_IFACE_OVS;
|
|
|
|
|
else if (nm_streq(type, NM_SETTING_OVS_INTERFACE_SETTING_NAME)) {
|
|
|
|
|
NMSettingOvsInterface *s_ovs_iface = NULL;
|
2021-11-09 13:28:54 +01:00
|
|
|
const char *ovs_iface_type;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-02-18 14:00:10 +01:00
|
|
|
if (connection)
|
|
|
|
|
s_ovs_iface = nm_connection_get_setting_ovs_interface(connection);
|
|
|
|
|
_nm_setting_ovs_interface_verify_interface_type(
|
|
|
|
|
s_ovs_iface,
|
|
|
|
|
s_ovs_iface ? nm_setting_ovs_interface_get_interface_type(s_ovs_iface) : NULL,
|
|
|
|
|
connection,
|
|
|
|
|
FALSE,
|
|
|
|
|
NULL,
|
|
|
|
|
&ovs_iface_type,
|
|
|
|
|
NULL);
|
|
|
|
|
if (!ovs_iface_type) {
|
|
|
|
|
/* We cannot determine to OVS interface type. Consequently, we cannot
|
|
|
|
|
* fully validate the interface name.
|
|
|
|
|
*
|
|
|
|
|
* If we have a connection (and we do a full validation anyway), skip the
|
|
|
|
|
* check. The connection will fail validation when we validate the OVS setting.
|
|
|
|
|
*
|
|
|
|
|
* Otherwise, do the most basic validation.
|
|
|
|
|
*/
|
|
|
|
|
if (connection)
|
|
|
|
|
goto after_interface_name;
|
|
|
|
|
iface_type = NMU_IFACE_ANY;
|
|
|
|
|
} else if (NM_IN_STRSET(ovs_iface_type, "patch")) {
|
|
|
|
|
/* this interface type is internal to OVS. */
|
|
|
|
|
iface_type = NMU_IFACE_OVS;
|
|
|
|
|
} else {
|
|
|
|
|
/* This interface type also requires a netdev. We need to validate
|
|
|
|
|
* for both OVS and KERNEL. */
|
|
|
|
|
nm_assert(NM_IN_STRSET(ovs_iface_type, "internal", "system", "dpdk"));
|
|
|
|
|
iface_type = NMU_IFACE_OVS_AND_KERNEL;
|
|
|
|
|
}
|
|
|
|
|
} else
|
|
|
|
|
iface_type = NMU_IFACE_KERNEL;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-02-18 14:00:10 +01:00
|
|
|
if (!nm_utils_ifname_valid(priv->interface_name, iface_type, &tmp_error)) {
|
2020-02-06 17:17:49 +01:00
|
|
|
g_set_error(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_INVALID_PROPERTY,
|
|
|
|
|
"'%s': %s",
|
|
|
|
|
priv->interface_name,
|
|
|
|
|
tmp_error->message);
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_CONNECTION_SETTING_NAME,
|
|
|
|
|
NM_SETTING_CONNECTION_INTERFACE_NAME);
|
|
|
|
|
g_error_free(tmp_error);
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
}
|
2020-02-18 14:00:10 +01:00
|
|
|
after_interface_name:
|
2020-02-06 17:17:49 +01:00
|
|
|
|
2020-12-09 10:41:05 +01:00
|
|
|
if (!_nm_connection_detect_slave_type_full(self,
|
|
|
|
|
connection,
|
|
|
|
|
&slave_type,
|
|
|
|
|
&normerr_slave_setting_type,
|
|
|
|
|
&normerr_missing_slave_type,
|
|
|
|
|
&normerr_missing_slave_type_port,
|
|
|
|
|
error))
|
|
|
|
|
return FALSE;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-12-09 10:41:05 +01:00
|
|
|
if (nm_streq(type, NM_SETTING_OVS_PORT_SETTING_NAME) && slave_type
|
|
|
|
|
&& !nm_streq(slave_type, NM_SETTING_OVS_BRIDGE_SETTING_NAME)) {
|
2017-08-01 18:36:34 +02:00
|
|
|
g_set_error(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_MISSING_PROPERTY,
|
2018-07-10 15:09:40 +02:00
|
|
|
_("'%s' connections must be enslaved to '%s', not '%s'"),
|
2017-08-01 18:36:34 +02:00
|
|
|
NM_SETTING_OVS_PORT_SETTING_NAME,
|
2018-07-10 15:09:40 +02:00
|
|
|
NM_SETTING_OVS_BRIDGE_SETTING_NAME,
|
|
|
|
|
slave_type);
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_CONNECTION_SETTING_NAME,
|
|
|
|
|
NM_SETTING_CONNECTION_SLAVE_TYPE);
|
2017-08-01 18:36:34 +02:00
|
|
|
return FALSE;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2021-10-20 16:13:14 +02:00
|
|
|
if (!NM_IN_SET(priv->metered, NM_METERED_UNKNOWN, NM_METERED_NO, NM_METERED_YES)) {
|
2015-04-27 17:45:53 +02:00
|
|
|
g_set_error(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_INVALID_PROPERTY,
|
|
|
|
|
_("metered value %d is not valid"),
|
|
|
|
|
priv->metered);
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_CONNECTION_SETTING_NAME,
|
|
|
|
|
NM_SETTING_CONNECTION_METERED);
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2018-08-31 10:48:18 +02:00
|
|
|
if (priv->mdns < (int) NM_SETTING_CONNECTION_MDNS_DEFAULT
|
|
|
|
|
|| priv->mdns > (int) NM_SETTING_CONNECTION_MDNS_YES) {
|
2017-12-15 12:11:53 +01:00
|
|
|
g_set_error(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_INVALID_PROPERTY,
|
2018-08-31 10:48:18 +02:00
|
|
|
_("value %d is not valid"),
|
|
|
|
|
priv->mdns);
|
2017-12-15 12:11:53 +01:00
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_CONNECTION_SETTING_NAME,
|
|
|
|
|
NM_SETTING_CONNECTION_MDNS);
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2018-08-31 10:48:18 +02:00
|
|
|
if (priv->llmnr < (int) NM_SETTING_CONNECTION_LLMNR_DEFAULT
|
|
|
|
|
|| priv->llmnr > (int) NM_SETTING_CONNECTION_LLMNR_YES) {
|
|
|
|
|
g_set_error(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_INVALID_PROPERTY,
|
|
|
|
|
_("value %d is not valid"),
|
|
|
|
|
priv->llmnr);
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_CONNECTION_SETTING_NAME,
|
|
|
|
|
NM_SETTING_CONNECTION_LLMNR);
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2021-10-03 19:16:01 +02:00
|
|
|
if (priv->dns_over_tls < (int) NM_SETTING_CONNECTION_DNS_OVER_TLS_DEFAULT
|
|
|
|
|
|| priv->dns_over_tls > (int) NM_SETTING_CONNECTION_DNS_OVER_TLS_YES) {
|
|
|
|
|
g_set_error(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_INVALID_PROPERTY,
|
|
|
|
|
_("value %d is not valid"),
|
|
|
|
|
priv->dns_over_tls);
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_CONNECTION_SETTING_NAME,
|
|
|
|
|
NM_SETTING_CONNECTION_DNS_OVER_TLS);
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
|
2022-07-18 21:24:09 +02:00
|
|
|
if (priv->mptcp_flags != 0) {
|
|
|
|
|
if (NM_FLAGS_HAS(priv->mptcp_flags, NM_MPTCP_FLAGS_DISABLED)) {
|
|
|
|
|
if (priv->mptcp_flags != NM_MPTCP_FLAGS_DISABLED) {
|
|
|
|
|
g_set_error_literal(
|
|
|
|
|
error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_INVALID_PROPERTY,
|
|
|
|
|
_("\"disabled\" flag cannot be combined with other MPTCP flags"));
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_CONNECTION_SETTING_NAME,
|
|
|
|
|
NM_SETTING_CONNECTION_MPTCP_FLAGS);
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
guint32 f;
|
|
|
|
|
|
|
|
|
|
if (NM_FLAGS_ALL(priv->mptcp_flags, NM_MPTCP_FLAGS_SIGNAL | NM_MPTCP_FLAGS_FULLMESH)) {
|
|
|
|
|
g_set_error_literal(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_INVALID_PROPERTY,
|
|
|
|
|
_("cannot set both \"signal\" and \"fullmesh\" MPTCP flags"));
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_CONNECTION_SETTING_NAME,
|
|
|
|
|
NM_SETTING_CONNECTION_MPTCP_FLAGS);
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
mptcp: rework "connection.mptcp-flags" for enabling MPTCP
1) The "enabled-on-global-iface" flag was odd. Instead, have only
and "enabled" flag and skip (by default) endpoints on interface
that have no default route. With the new flag "also-without-default-route",
this can be overruled. So previous "enabled-on-global-default" now is
the same as "enabled", and "enabled" from before behaves now like
"enabled,also-without-default-route".
2) What was also odd, as that the fallback default value for the flags
depends on "/proc/sys/net/mptcp/enabled". There was not one fixed
fallback default, instead the used fallback value was either
"enabled-on-global-iface,subflow" or "disabled".
Usually that is not a problem (e.g. the default value for
"ipv6.ip6-privacy" also depends on use_tempaddr sysctl). In this case
it is a problem, because the mptcp-flags (for better or worse) encode
different things at the same time.
Consider that the mptcp-flags can also have their default configured in
"NetworkManager.conf", a user who wants to switch the address flags
could previously do:
[connection.mptcp]
connection.mptcp-flags=0x32 # enabled-on-global-iface,signal,subflow
but then the global toggle "/proc/sys/net/mptcp/enabled" was no longer
honored. That means, MPTCP handling was always on, even if the sysctl was
disabled. Now, "enabled" means that it's only enabled if the sysctl
is enabled too. Now the user could write to "NetworkManager.conf"
[connection.mptcp]
connection.mptcp-flags=0x32 # enabled,signal,subflow
and MPTCP handling would still be disabled unless the sysctl
is enabled.
There is now also a new flag "also-without-sysctl", so if you want
to really enable MPTCP handling regardless of the sysctl, you can.
The point of that might be, that we still can configure endpoints,
even if kernel won't do anything with them. Then you could just flip
the sysctl, and it would start working (as NetworkManager configured
the endpoints already).
Fixes: eb083eece5a2 ('all: add NMMptcpFlags and connection.mptcp-flags property')
(cherry picked from commit c00873e08f4d0bc4a3f0b8a93beb793fcab78afa)
2022-08-25 09:40:46 +02:00
|
|
|
f = priv->mptcp_flags | ((guint32) NM_MPTCP_FLAGS_ENABLED);
|
2022-07-18 21:24:09 +02:00
|
|
|
if (f != nm_mptcp_flags_normalize(f)) {
|
|
|
|
|
g_set_error(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_INVALID_PROPERTY,
|
|
|
|
|
_("value %u is not a valid combination of MPTCP flags"),
|
|
|
|
|
priv->mptcp_flags);
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_CONNECTION_SETTING_NAME,
|
|
|
|
|
NM_SETTING_CONNECTION_MPTCP_FLAGS);
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
all: add connection.multi-connect property for wildcard profiles
Add a new option that allows to activate a profile multiple times
(at the same time). Previoulsy, all profiles were implicitly
NM_SETTING_CONNECTION_MULTI_CONNECT_SINGLE, meaning, that activating
a profile that is already active will deactivate it first.
This will make more sense, as we also add more match-options how
profiles can be restricted to particular devices. We already have
connection.type, connection.interface-name, and (ethernet|wifi).mac-address
to restrict a profile to particular devices. For example, it is however
not possible to specify a wildcard like "eth*" to match a profile to
a set of devices by interface-name. That is another missing feature,
and once we extend the matching capabilities, it makes more sense to
activate a profile multiple times.
See also https://bugzilla.redhat.com/show_bug.cgi?id=997998, which
previously changed that a connection is restricted to a single activation
at a time. This work relaxes that again.
This only adds the new property, it is not used nor implemented yet.
https://bugzilla.redhat.com/show_bug.cgi?id=1555012
2018-04-10 11:45:35 +02:00
|
|
|
if (!NM_IN_SET(priv->multi_connect,
|
|
|
|
|
(int) NM_CONNECTION_MULTI_CONNECT_DEFAULT,
|
|
|
|
|
(int) NM_CONNECTION_MULTI_CONNECT_SINGLE,
|
|
|
|
|
(int) NM_CONNECTION_MULTI_CONNECT_MANUAL_MULTIPLE,
|
|
|
|
|
(int) NM_CONNECTION_MULTI_CONNECT_MULTIPLE)) {
|
|
|
|
|
g_set_error(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_INVALID_PROPERTY,
|
|
|
|
|
_("value %d is not valid"),
|
|
|
|
|
priv->multi_connect);
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_CONNECTION_SETTING_NAME,
|
|
|
|
|
NM_SETTING_CONNECTION_MULTI_CONNECT);
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-04-24 09:31:30 +02:00
|
|
|
if (priv->mud_url) {
|
|
|
|
|
if (!priv->mud_url[0]) {
|
|
|
|
|
g_set_error_literal(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_INVALID_PROPERTY,
|
|
|
|
|
_("property is empty"));
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
nm_setting_get_name(setting),
|
|
|
|
|
NM_SETTING_CONNECTION_MUD_URL);
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
2020-04-25 07:46:56 +02:00
|
|
|
if (nm_streq(priv->mud_url, NM_CONNECTION_MUD_URL_NONE)) {
|
|
|
|
|
/* pass */
|
|
|
|
|
} else {
|
|
|
|
|
if (strlen(priv->mud_url) > 255) {
|
|
|
|
|
g_set_error_literal(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_INVALID_PROPERTY,
|
|
|
|
|
_("DHCP option cannot be longer than 255 characters"));
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
nm_setting_get_name(setting),
|
|
|
|
|
NM_SETTING_CONNECTION_MUD_URL);
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
if (!nm_sd_http_url_is_valid_https(priv->mud_url)) {
|
|
|
|
|
g_set_error_literal(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_INVALID_PROPERTY,
|
|
|
|
|
_("MUD URL is not a valid URL"));
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
nm_setting_get_name(setting),
|
|
|
|
|
NM_SETTING_CONNECTION_MUD_URL);
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
2020-04-24 09:31:30 +02:00
|
|
|
}
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
if (priv->permissions) {
|
|
|
|
|
guint i;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < priv->permissions->len; i++) {
|
2022-09-08 12:05:56 +02:00
|
|
|
const Permission *permissions = &nm_g_array_index(priv->permissions, Permission, i);
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
|
|
|
|
|
if (permissions->ptype != PERM_TYPE_USER) {
|
|
|
|
|
g_set_error_literal(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_INVALID_PROPERTY,
|
|
|
|
|
_("invalid permissions not in format \"user:$UNAME[:]\""));
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
nm_setting_get_name(setting),
|
|
|
|
|
NM_SETTING_CONNECTION_PERMISSIONS);
|
|
|
|
|
return FALSE;
|
|
|
|
|
}
|
|
|
|
|
nm_assert(nm_settings_connection_validate_permission_user(permissions->item, -1));
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2014-07-07 17:05:10 +02:00
|
|
|
/* *** errors above here should be always fatal, below NORMALIZABLE_ERROR *** */
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-12-01 13:03:23 +01:00
|
|
|
if (!priv->uuid) {
|
|
|
|
|
g_set_error_literal(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_MISSING_PROPERTY,
|
|
|
|
|
_("property is missing"));
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_CONNECTION_SETTING_NAME,
|
|
|
|
|
NM_SETTING_CONNECTION_UUID);
|
|
|
|
|
return NM_SETTING_VERIFY_NORMALIZABLE_ERROR;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-08 18:36:02 +02:00
|
|
|
if (normerr_base_type) {
|
|
|
|
|
g_set_error(error,
|
libnm-core: merge NMSetting*Error into NMConnectionError
Each setting type was defining its own error type, but most of them
had exactly the same three errors ("unknown", "missing property", and
"invalid property"), and none of the other values was of much use
programmatically anyway.
So, this commit merges NMSettingError, NMSettingAdslError, etc, all
into NMConnectionError. (The reason for merging into NMConnectionError
rather than NMSettingError is that we also already have
"NMSettingsError", for errors related to the settings service, so
"NMConnectionError" is a less-confusable name for settings/connection
errors than "NMSettingError".)
Also, make sure that all of the affected error messages are localized,
and (where appropriate) prefix them with the relevant property name.
Renamed error codes:
NM_SETTING_ERROR_PROPERTY_NOT_FOUND -> NM_CONNECTION_ERROR_PROPERTY_NOT_FOUND
NM_SETTING_ERROR_PROPERTY_NOT_SECRET -> NM_CONNECTION_ERROR_PROPERTY_NOT_SECRET
Remapped error codes:
NM_SETTING_*_ERROR_MISSING_PROPERTY -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_*_ERROR_INVALID_PROPERTY -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_ERROR_PROPERTY_TYPE_MISMATCH -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BLUETOOTH_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_INVALID_SETTING
NM_SETTING_BOND_ERROR_INVALID_OPTION -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BOND_ERROR_MISSING_OPTION -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_CONNECTION_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_CONNECTION_ERROR_SLAVE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_IP4_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_IP6_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_VLAN_ERROR_INVALID_PARENT -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_MISSING_802_1X_SETTING -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_802_1X -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_USERNAME -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_SHARED_KEY_REQUIRES_WEP -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_ERROR_CHANNEL_REQUIRES_BAND -> NM_CONNECTION_ERROR_MISSING_PROPERTY
Dropped error codes (were previously defined but unused):
NM_SETTING_CDMA_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_CONNECTION_ERROR_IP_CONFIG_NOT_ALLOWED
NM_SETTING_GSM_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_PPP_ERROR_REQUIRE_MPPE_NOT_ALLOWED
NM_SETTING_PPPOE_ERROR_MISSING_PPP_SETTING
NM_SETTING_SERIAL_ERROR_MISSING_PPP_SETTING
NM_SETTING_WIRELESS_ERROR_MISSING_SECURITY_SETTING
2014-10-20 13:52:23 -04:00
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_MISSING_PROPERTY,
|
2014-07-08 18:36:02 +02:00
|
|
|
_("property type should be set to '%s'"),
|
|
|
|
|
nm_setting_get_name(normerr_base_type));
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_CONNECTION_SETTING_NAME,
|
|
|
|
|
NM_SETTING_CONNECTION_TYPE);
|
|
|
|
|
return NM_SETTING_VERIFY_NORMALIZABLE_ERROR;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-08 18:36:02 +02:00
|
|
|
if (normerr_base_setting) {
|
|
|
|
|
_set_error_missing_base_setting(error, priv->type);
|
|
|
|
|
return NM_SETTING_VERIFY_NORMALIZABLE_ERROR;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-07 17:05:10 +02:00
|
|
|
if (normerr_slave_setting_type) {
|
|
|
|
|
g_set_error(error,
|
libnm-core: merge NMSetting*Error into NMConnectionError
Each setting type was defining its own error type, but most of them
had exactly the same three errors ("unknown", "missing property", and
"invalid property"), and none of the other values was of much use
programmatically anyway.
So, this commit merges NMSettingError, NMSettingAdslError, etc, all
into NMConnectionError. (The reason for merging into NMConnectionError
rather than NMSettingError is that we also already have
"NMSettingsError", for errors related to the settings service, so
"NMConnectionError" is a less-confusable name for settings/connection
errors than "NMSettingError".)
Also, make sure that all of the affected error messages are localized,
and (where appropriate) prefix them with the relevant property name.
Renamed error codes:
NM_SETTING_ERROR_PROPERTY_NOT_FOUND -> NM_CONNECTION_ERROR_PROPERTY_NOT_FOUND
NM_SETTING_ERROR_PROPERTY_NOT_SECRET -> NM_CONNECTION_ERROR_PROPERTY_NOT_SECRET
Remapped error codes:
NM_SETTING_*_ERROR_MISSING_PROPERTY -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_*_ERROR_INVALID_PROPERTY -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_ERROR_PROPERTY_TYPE_MISMATCH -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BLUETOOTH_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_INVALID_SETTING
NM_SETTING_BOND_ERROR_INVALID_OPTION -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BOND_ERROR_MISSING_OPTION -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_CONNECTION_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_CONNECTION_ERROR_SLAVE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_IP4_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_IP6_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_VLAN_ERROR_INVALID_PARENT -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_MISSING_802_1X_SETTING -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_802_1X -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_USERNAME -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_SHARED_KEY_REQUIRES_WEP -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_ERROR_CHANNEL_REQUIRES_BAND -> NM_CONNECTION_ERROR_MISSING_PROPERTY
Dropped error codes (were previously defined but unused):
NM_SETTING_CDMA_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_CONNECTION_ERROR_IP_CONFIG_NOT_ALLOWED
NM_SETTING_GSM_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_PPP_ERROR_REQUIRE_MPPE_NOT_ALLOWED
NM_SETTING_PPPOE_ERROR_MISSING_PPP_SETTING
NM_SETTING_SERIAL_ERROR_MISSING_PPP_SETTING
NM_SETTING_WIRELESS_ERROR_MISSING_SECURITY_SETTING
2014-10-20 13:52:23 -04:00
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_MISSING_SETTING,
|
2014-07-07 17:05:10 +02:00
|
|
|
_("slave-type '%s' requires a '%s' setting in the connection"),
|
|
|
|
|
priv->slave_type,
|
|
|
|
|
normerr_slave_setting_type);
|
libnm-core: merge NMSetting*Error into NMConnectionError
Each setting type was defining its own error type, but most of them
had exactly the same three errors ("unknown", "missing property", and
"invalid property"), and none of the other values was of much use
programmatically anyway.
So, this commit merges NMSettingError, NMSettingAdslError, etc, all
into NMConnectionError. (The reason for merging into NMConnectionError
rather than NMSettingError is that we also already have
"NMSettingsError", for errors related to the settings service, so
"NMConnectionError" is a less-confusable name for settings/connection
errors than "NMSettingError".)
Also, make sure that all of the affected error messages are localized,
and (where appropriate) prefix them with the relevant property name.
Renamed error codes:
NM_SETTING_ERROR_PROPERTY_NOT_FOUND -> NM_CONNECTION_ERROR_PROPERTY_NOT_FOUND
NM_SETTING_ERROR_PROPERTY_NOT_SECRET -> NM_CONNECTION_ERROR_PROPERTY_NOT_SECRET
Remapped error codes:
NM_SETTING_*_ERROR_MISSING_PROPERTY -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_*_ERROR_INVALID_PROPERTY -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_ERROR_PROPERTY_TYPE_MISMATCH -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BLUETOOTH_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_INVALID_SETTING
NM_SETTING_BOND_ERROR_INVALID_OPTION -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BOND_ERROR_MISSING_OPTION -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_CONNECTION_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_CONNECTION_ERROR_SLAVE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_IP4_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_IP6_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_VLAN_ERROR_INVALID_PARENT -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_MISSING_802_1X_SETTING -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_802_1X -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_USERNAME -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_SHARED_KEY_REQUIRES_WEP -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_ERROR_CHANNEL_REQUIRES_BAND -> NM_CONNECTION_ERROR_MISSING_PROPERTY
Dropped error codes (were previously defined but unused):
NM_SETTING_CDMA_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_CONNECTION_ERROR_IP_CONFIG_NOT_ALLOWED
NM_SETTING_GSM_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_PPP_ERROR_REQUIRE_MPPE_NOT_ALLOWED
NM_SETTING_PPPOE_ERROR_MISSING_PPP_SETTING
NM_SETTING_SERIAL_ERROR_MISSING_PPP_SETTING
NM_SETTING_WIRELESS_ERROR_MISSING_SECURITY_SETTING
2014-10-20 13:52:23 -04:00
|
|
|
g_prefix_error(error, "%s: ", normerr_slave_setting_type);
|
2014-07-07 17:05:10 +02:00
|
|
|
return NM_SETTING_VERIFY_NORMALIZABLE_ERROR;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-07 17:05:10 +02:00
|
|
|
if (normerr_missing_slave_type) {
|
|
|
|
|
g_set_error(error,
|
libnm-core: merge NMSetting*Error into NMConnectionError
Each setting type was defining its own error type, but most of them
had exactly the same three errors ("unknown", "missing property", and
"invalid property"), and none of the other values was of much use
programmatically anyway.
So, this commit merges NMSettingError, NMSettingAdslError, etc, all
into NMConnectionError. (The reason for merging into NMConnectionError
rather than NMSettingError is that we also already have
"NMSettingsError", for errors related to the settings service, so
"NMConnectionError" is a less-confusable name for settings/connection
errors than "NMSettingError".)
Also, make sure that all of the affected error messages are localized,
and (where appropriate) prefix them with the relevant property name.
Renamed error codes:
NM_SETTING_ERROR_PROPERTY_NOT_FOUND -> NM_CONNECTION_ERROR_PROPERTY_NOT_FOUND
NM_SETTING_ERROR_PROPERTY_NOT_SECRET -> NM_CONNECTION_ERROR_PROPERTY_NOT_SECRET
Remapped error codes:
NM_SETTING_*_ERROR_MISSING_PROPERTY -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_*_ERROR_INVALID_PROPERTY -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_ERROR_PROPERTY_TYPE_MISMATCH -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BLUETOOTH_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_INVALID_SETTING
NM_SETTING_BOND_ERROR_INVALID_OPTION -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_BOND_ERROR_MISSING_OPTION -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_CONNECTION_ERROR_TYPE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_CONNECTION_ERROR_SLAVE_SETTING_NOT_FOUND -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_IP4_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_IP6_CONFIG_ERROR_NOT_ALLOWED_FOR_METHOD -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_VLAN_ERROR_INVALID_PARENT -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_MISSING_802_1X_SETTING -> NM_CONNECTION_ERROR_MISSING_SETTING
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_802_1X -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_LEAP_REQUIRES_USERNAME -> NM_CONNECTION_ERROR_MISSING_PROPERTY
NM_SETTING_WIRELESS_SECURITY_ERROR_SHARED_KEY_REQUIRES_WEP -> NM_CONNECTION_ERROR_INVALID_PROPERTY
NM_SETTING_WIRELESS_ERROR_CHANNEL_REQUIRES_BAND -> NM_CONNECTION_ERROR_MISSING_PROPERTY
Dropped error codes (were previously defined but unused):
NM_SETTING_CDMA_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_CONNECTION_ERROR_IP_CONFIG_NOT_ALLOWED
NM_SETTING_GSM_ERROR_MISSING_SERIAL_SETTING
NM_SETTING_PPP_ERROR_REQUIRE_MPPE_NOT_ALLOWED
NM_SETTING_PPPOE_ERROR_MISSING_PPP_SETTING
NM_SETTING_SERIAL_ERROR_MISSING_PPP_SETTING
NM_SETTING_WIRELESS_ERROR_MISSING_SECURITY_SETTING
2014-10-20 13:52:23 -04:00
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_MISSING_PROPERTY,
|
2014-11-20 12:33:49 +01:00
|
|
|
_("Detect a slave connection with '%s' set and a port type '%s'. '%s' should "
|
|
|
|
|
"be set to '%s'"),
|
|
|
|
|
NM_SETTING_CONNECTION_MASTER,
|
|
|
|
|
normerr_missing_slave_type_port,
|
|
|
|
|
NM_SETTING_CONNECTION_SLAVE_TYPE,
|
|
|
|
|
normerr_missing_slave_type);
|
2014-07-07 17:05:10 +02:00
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_CONNECTION_SETTING_NAME,
|
|
|
|
|
NM_SETTING_CONNECTION_SLAVE_TYPE);
|
|
|
|
|
return NM_SETTING_VERIFY_NORMALIZABLE_ERROR;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2017-03-01 13:50:59 +01:00
|
|
|
if (connection) {
|
|
|
|
|
gboolean has_bridge_port = FALSE;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2017-03-01 13:50:59 +01:00
|
|
|
if ((!nm_streq0(priv->slave_type, NM_SETTING_BRIDGE_SETTING_NAME)
|
|
|
|
|
&& (has_bridge_port =
|
|
|
|
|
!!nm_connection_get_setting_by_name(connection,
|
|
|
|
|
NM_SETTING_BRIDGE_PORT_SETTING_NAME)))
|
|
|
|
|
|| (!nm_streq0(priv->slave_type, NM_SETTING_TEAM_SETTING_NAME)
|
|
|
|
|
&& nm_connection_get_setting_by_name(connection,
|
|
|
|
|
NM_SETTING_TEAM_PORT_SETTING_NAME))) {
|
|
|
|
|
g_set_error(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_INVALID_SETTING,
|
|
|
|
|
_("A slave connection with '%s' set to '%s' cannot have a '%s' setting"),
|
|
|
|
|
NM_SETTING_CONNECTION_SLAVE_TYPE,
|
|
|
|
|
priv->slave_type ?: "",
|
|
|
|
|
has_bridge_port ? NM_SETTING_BRIDGE_PORT_SETTING_NAME
|
|
|
|
|
: NM_SETTING_TEAM_PORT_SETTING_NAME);
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_CONNECTION_SETTING_NAME,
|
|
|
|
|
NM_SETTING_CONNECTION_SLAVE_TYPE);
|
|
|
|
|
return NM_SETTING_VERIFY_NORMALIZABLE_ERROR;
|
|
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
}
|
|
|
|
|
|
2021-05-02 22:42:51 +02:00
|
|
|
if (uuid_was_normalized) {
|
|
|
|
|
g_set_error_literal(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_MISSING_PROPERTY,
|
|
|
|
|
_("UUID needs normalization"));
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_CONNECTION_SETTING_NAME,
|
|
|
|
|
NM_SETTING_CONNECTION_UUID);
|
|
|
|
|
return NM_SETTING_VERIFY_NORMALIZABLE;
|
|
|
|
|
}
|
|
|
|
|
|
2022-01-24 17:24:25 +01:00
|
|
|
if (!_nm_setting_connection_verify_secondaries(priv->secondaries.arr, error))
|
libnm: verify and normalize "connection.secondaries"
So far, we didn't verify the secondary connections at all.
But these really are supposed to be UUIDs.
As we now also normalize "connection.uuid" to be in a strict
format, the user might have profiles with non-normalized UUIDs.
In that case, the "connection.uuid" would be normalized, but
"connection.secondaries" no longer matches. We can fix that by
also normalizing "connection.secondaries". OK, this is not a very good
reason, because it's unlikely to affect any users in practice ('though
it's easy to reproduce).
A better reason is that the secondary setting really should be well
defined and verified. As we didn't do that so far, we cannot simply
outright reject invalid settings. What this patch does instead, is
silently changing the profile to only contain valid settings.
That has it's own problems, like that the user setting an invalid
value does not get an error nor the desired(?) outcome.
But of all the bad choices, normalizing seems the most sensible
one.
Note that in practice, most client applications don't rely on setting
arbitrary (invalid) "UUIDs". They simply expect to be able to set valid
UUIDs, which they still are. For example, nm-connection-editor presents
a drop down list of VPN profile, and nmcli also resolves connection IDs
to the UUID. That is, clients already have an intimate understanding of
this setting, and don't blindly set arbitrary values. Hence, this
normalization is unlikely to hit users in practice. But what it gives
is the guarantee that a verified connection only contains valid UUIDs.
Now all UUIDs will be normalized, invalid entries removed, and the list
made unique.
2021-06-02 15:15:43 +02:00
|
|
|
return NM_SETTING_VERIFY_NORMALIZABLE;
|
|
|
|
|
|
2023-03-14 09:00:14 +01:00
|
|
|
if (priv->read_only) {
|
|
|
|
|
g_set_error_literal(error,
|
|
|
|
|
NM_CONNECTION_ERROR,
|
|
|
|
|
NM_CONNECTION_ERROR_MISSING_PROPERTY,
|
|
|
|
|
_("read-only is deprecated and not settable for the user"));
|
|
|
|
|
g_prefix_error(error,
|
|
|
|
|
"%s.%s: ",
|
|
|
|
|
NM_SETTING_CONNECTION_SETTING_NAME,
|
|
|
|
|
NM_SETTING_CONNECTION_READ_ONLY);
|
|
|
|
|
return NM_SETTING_VERIFY_NORMALIZABLE;
|
|
|
|
|
}
|
|
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
return TRUE;
|
|
|
|
|
}
|
|
|
|
|
|
2014-09-15 13:30:07 -04:00
|
|
|
static const char *
|
2020-02-17 16:29:25 +01:00
|
|
|
find_virtual_interface_name(GVariant *connection_dict, GVariant **variant_to_free)
|
2014-08-04 19:57:20 -04:00
|
|
|
{
|
2021-11-09 13:28:54 +01:00
|
|
|
GVariant *setting_dict;
|
2014-08-16 10:09:48 -04:00
|
|
|
const char *interface_name;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-02-17 16:29:25 +01:00
|
|
|
nm_assert(variant_to_free && !*variant_to_free);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-08-16 10:09:48 -04:00
|
|
|
setting_dict = g_variant_lookup_value(connection_dict,
|
|
|
|
|
NM_SETTING_BOND_SETTING_NAME,
|
|
|
|
|
NM_VARIANT_TYPE_SETTING);
|
|
|
|
|
if (!setting_dict)
|
|
|
|
|
setting_dict = g_variant_lookup_value(connection_dict,
|
|
|
|
|
NM_SETTING_BRIDGE_SETTING_NAME,
|
|
|
|
|
NM_VARIANT_TYPE_SETTING);
|
|
|
|
|
if (!setting_dict)
|
|
|
|
|
setting_dict = g_variant_lookup_value(connection_dict,
|
|
|
|
|
NM_SETTING_TEAM_SETTING_NAME,
|
|
|
|
|
NM_VARIANT_TYPE_SETTING);
|
|
|
|
|
if (!setting_dict)
|
|
|
|
|
setting_dict = g_variant_lookup_value(connection_dict,
|
|
|
|
|
NM_SETTING_VLAN_SETTING_NAME,
|
|
|
|
|
NM_VARIANT_TYPE_SETTING);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-08-16 10:09:48 -04:00
|
|
|
if (!setting_dict)
|
2014-09-15 13:30:07 -04:00
|
|
|
return NULL;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-02-17 16:29:25 +01:00
|
|
|
*variant_to_free = setting_dict;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-08-04 19:57:20 -04:00
|
|
|
/* All of the deprecated virtual interface name properties were named "interface-name". */
|
2014-08-16 10:09:48 -04:00
|
|
|
if (!g_variant_lookup(setting_dict, "interface-name", "&s", &interface_name))
|
2015-02-06 16:36:55 +01:00
|
|
|
interface_name = NULL;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-08-16 10:09:48 -04:00
|
|
|
return interface_name;
|
2014-09-15 13:30:07 -04:00
|
|
|
}
|
2014-08-04 19:57:20 -04:00
|
|
|
|
libnm-core: allow strict and relaxed error behavior for _nm_setting_new_from_dbus()
In some situations, we want strict checking of errors, for example when
NetworkManager receives a new connection from a client, the connection
must make sense as a whole (and since NetworkManager service is backward
compatible to the clients and not the other way around, there is no
excuse for sending invalid data to the server).
In other situations, we want a best-effort behavior. Like when
NetworkManager sends a connection to its clients, those clients
want to extract as many properties as they understand, but in order
to be forward compatible against newer server versions, invalid
or unknown properties must be accepted.
Previously, a mixture of both was done. Some issues caused a failure
to create a new NMSetting, other invalid parts were just silently
ignored or triggered a g_warning() in glib.
Now allow for both. When doing strict-validation, be more strict and
reject all unknown properties and catch when the user sets an invalid
argument. On the other hand, allow for a best-effort mode that
effectively cannot fail and will return a new NMSetting instance.
For now, add NMSettingParseFlags so that the caller can choose the
old behavior, strict parsing, or best effort.
This patch doesn't have any externally visible change except that
no more g_warnings will be emitted.
2016-03-18 13:42:50 +01:00
|
|
|
static gboolean
|
libnm: use macros function arguments for NMSettInfoPropertType
These functions tend to have many arguments. They are also quite som
boilerplate to implement the hundereds of properties we have, while
we want that properties have common behaviors and similarities.
Instead of repeatedly spelling out the function arguments, use a macro.
Advantages:
- the usage of a _NM_SETT_INFO_PROP_*_FCN_ARGS macro signals that this
is an implementation of a property. You can now grep for these macros
to find all implementation. That was previously rather imprecise, you
could only `git grep '\.to_dbus_fcn'` to find the uses, but not the
implementations.
As the goal is to keep properties "similar", there is a desire to
reduce the number of similar implementations and to find them.
- changing the arguments now no longer will require you to go through
all implementations. At least not, if you merely add an argument that
has a reasonable default behavior and does not require explicit
handling by most implementation.
- it's convenient to be able to patch the argument list to let the
compiler help to reason about something. For example, the
"connection_dict" argument to from_dbus_fcn() is usually unused.
If you'd like to find who uses it, rename the parameter, and
review the (few) compiler errors.
- it does save 573 LOC of boilerplate with no actual logic or useful
information. I argue, that this simplifies the code and review, by
increasing the relative amount of actually meaningful code.
Disadvantages:
- the user no longer directly sees the argument list. They would need
cscope/ctags or an IDE to jump to the macro definition and conveniently
see all arguments.
Also use _nm_nil, so that clang-format interprets this as a function
parameter list. Otherwise, it formats the function differently.
2021-07-26 23:45:31 +02:00
|
|
|
nm_setting_connection_no_interface_name(_NM_SETT_INFO_PROP_MISSING_FROM_DBUS_FCN_ARGS _nm_nil)
|
2014-09-15 13:30:07 -04:00
|
|
|
{
|
2021-11-09 13:28:54 +01:00
|
|
|
const char *virtual_interface_name;
|
2020-02-17 16:29:25 +01:00
|
|
|
gs_unref_variant GVariant *variant_to_free = NULL;
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-02-17 16:29:25 +01:00
|
|
|
virtual_interface_name = find_virtual_interface_name(connection_dict, &variant_to_free);
|
2014-09-15 13:30:07 -04:00
|
|
|
g_object_set(G_OBJECT(setting),
|
|
|
|
|
NM_SETTING_CONNECTION_INTERFACE_NAME,
|
|
|
|
|
virtual_interface_name,
|
|
|
|
|
NULL);
|
libnm-core: allow strict and relaxed error behavior for _nm_setting_new_from_dbus()
In some situations, we want strict checking of errors, for example when
NetworkManager receives a new connection from a client, the connection
must make sense as a whole (and since NetworkManager service is backward
compatible to the clients and not the other way around, there is no
excuse for sending invalid data to the server).
In other situations, we want a best-effort behavior. Like when
NetworkManager sends a connection to its clients, those clients
want to extract as many properties as they understand, but in order
to be forward compatible against newer server versions, invalid
or unknown properties must be accepted.
Previously, a mixture of both was done. Some issues caused a failure
to create a new NMSetting, other invalid parts were just silently
ignored or triggered a g_warning() in glib.
Now allow for both. When doing strict-validation, be more strict and
reject all unknown properties and catch when the user sets an invalid
argument. On the other hand, allow for a best-effort mode that
effectively cannot fail and will return a new NMSetting instance.
For now, add NMSettingParseFlags so that the caller can choose the
old behavior, strict parsing, or best effort.
This patch doesn't have any externally visible change except that
no more g_warnings will be emitted.
2016-03-18 13:42:50 +01:00
|
|
|
return TRUE;
|
2014-08-04 19:57:20 -04:00
|
|
|
}
|
|
|
|
|
|
libnm: rework compare_property() implementation for NMSetting
NMSetting's compare_property() has and had two callers:
nm_setting_compare() and nm_setting_diff().
compare_property() accepts a NMSettingCompareFlags argument, but
at the same time, both callers have another complex (and
inconsistent!) set of pre-checks for shortcuting the call of
compare_property(): should_compare_prop().
Merge should_compare_prop() into compare_property(). This way,
nm_setting_compare() and nm_setting_diff() has less additional
code, and are simpler to follow. Especially nm_setting_compare()
is now trivial. And nm_setting_diff() is still complicated, but
not related to the question how the property compares or whether
it should be compared at all.
If you want to know whether it should be compared, all you need to do
now is follow NMSettingClass.compare_property().
This changes function pointer NMSettingClass.compare_property(),
which is public API. However, no user can actually use this (and shall
not!), because _nm_setting_class_commit_full() etc. is private API. A
user outside of libnm-core cannot create his/her own subclasses of
NMSetting, and never could in the past. So, this API/ABI change doesn't
matter.
2019-01-09 09:08:39 +01:00
|
|
|
static NMTernary
|
libnm: use macros function arguments for NMSettInfoPropertType
These functions tend to have many arguments. They are also quite som
boilerplate to implement the hundereds of properties we have, while
we want that properties have common behaviors and similarities.
Instead of repeatedly spelling out the function arguments, use a macro.
Advantages:
- the usage of a _NM_SETT_INFO_PROP_*_FCN_ARGS macro signals that this
is an implementation of a property. You can now grep for these macros
to find all implementation. That was previously rather imprecise, you
could only `git grep '\.to_dbus_fcn'` to find the uses, but not the
implementations.
As the goal is to keep properties "similar", there is a desire to
reduce the number of similar implementations and to find them.
- changing the arguments now no longer will require you to go through
all implementations. At least not, if you merely add an argument that
has a reasonable default behavior and does not require explicit
handling by most implementation.
- it's convenient to be able to patch the argument list to let the
compiler help to reason about something. For example, the
"connection_dict" argument to from_dbus_fcn() is usually unused.
If you'd like to find who uses it, rename the parameter, and
review the (few) compiler errors.
- it does save 573 LOC of boilerplate with no actual logic or useful
information. I argue, that this simplifies the code and review, by
increasing the relative amount of actually meaningful code.
Disadvantages:
- the user no longer directly sees the argument list. They would need
cscope/ctags or an IDE to jump to the macro definition and conveniently
see all arguments.
Also use _nm_nil, so that clang-format interprets this as a function
parameter list. Otherwise, it formats the function differently.
2021-07-26 23:45:31 +02:00
|
|
|
compare_fcn_id(_NM_SETT_INFO_PROP_COMPARE_FCN_ARGS _nm_nil)
|
2014-07-24 08:53:33 -04:00
|
|
|
{
|
2021-06-29 14:37:16 +02:00
|
|
|
if (NM_FLAGS_HAS(flags, NM_SETTING_COMPARE_FLAG_IGNORE_ID))
|
|
|
|
|
return NM_TERNARY_DEFAULT;
|
|
|
|
|
|
2021-06-29 18:18:06 +02:00
|
|
|
return _nm_setting_property_compare_fcn_direct(sett_info,
|
|
|
|
|
property_info,
|
|
|
|
|
con_a,
|
|
|
|
|
set_a,
|
|
|
|
|
con_b,
|
|
|
|
|
set_b,
|
|
|
|
|
flags);
|
2021-06-29 14:37:16 +02:00
|
|
|
}
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2021-06-29 14:37:16 +02:00
|
|
|
static NMTernary
|
libnm: use macros function arguments for NMSettInfoPropertType
These functions tend to have many arguments. They are also quite som
boilerplate to implement the hundereds of properties we have, while
we want that properties have common behaviors and similarities.
Instead of repeatedly spelling out the function arguments, use a macro.
Advantages:
- the usage of a _NM_SETT_INFO_PROP_*_FCN_ARGS macro signals that this
is an implementation of a property. You can now grep for these macros
to find all implementation. That was previously rather imprecise, you
could only `git grep '\.to_dbus_fcn'` to find the uses, but not the
implementations.
As the goal is to keep properties "similar", there is a desire to
reduce the number of similar implementations and to find them.
- changing the arguments now no longer will require you to go through
all implementations. At least not, if you merely add an argument that
has a reasonable default behavior and does not require explicit
handling by most implementation.
- it's convenient to be able to patch the argument list to let the
compiler help to reason about something. For example, the
"connection_dict" argument to from_dbus_fcn() is usually unused.
If you'd like to find who uses it, rename the parameter, and
review the (few) compiler errors.
- it does save 573 LOC of boilerplate with no actual logic or useful
information. I argue, that this simplifies the code and review, by
increasing the relative amount of actually meaningful code.
Disadvantages:
- the user no longer directly sees the argument list. They would need
cscope/ctags or an IDE to jump to the macro definition and conveniently
see all arguments.
Also use _nm_nil, so that clang-format interprets this as a function
parameter list. Otherwise, it formats the function differently.
2021-07-26 23:45:31 +02:00
|
|
|
compare_fcn_timestamp(_NM_SETT_INFO_PROP_COMPARE_FCN_ARGS _nm_nil)
|
2021-06-29 14:37:16 +02:00
|
|
|
{
|
|
|
|
|
if (NM_FLAGS_HAS(flags, NM_SETTING_COMPARE_FLAG_IGNORE_TIMESTAMP))
|
|
|
|
|
return NM_TERNARY_DEFAULT;
|
|
|
|
|
|
|
|
|
|
return _nm_setting_property_compare_fcn_default(sett_info,
|
|
|
|
|
property_info,
|
|
|
|
|
con_a,
|
|
|
|
|
set_a,
|
|
|
|
|
con_b,
|
|
|
|
|
set_b,
|
|
|
|
|
flags);
|
2014-07-24 08:53:33 -04:00
|
|
|
}
|
|
|
|
|
|
2019-01-11 08:32:54 +01:00
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
static void
|
2019-01-11 08:32:54 +01:00
|
|
|
get_property(GObject *object, guint prop_id, GValue *value, GParamSpec *pspec)
|
2014-07-24 08:53:33 -04:00
|
|
|
{
|
2021-11-09 13:28:54 +01:00
|
|
|
NMSettingConnection *setting = NM_SETTING_CONNECTION(object);
|
2019-01-11 08:32:54 +01:00
|
|
|
NMSettingConnectionPrivate *priv = NM_SETTING_CONNECTION_GET_PRIVATE(setting);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
switch (prop_id) {
|
|
|
|
|
case PROP_PERMISSIONS:
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
{
|
|
|
|
|
char **strv;
|
|
|
|
|
gsize i, l;
|
|
|
|
|
|
|
|
|
|
l = nm_g_array_len(priv->permissions);
|
|
|
|
|
strv = g_new(char *, l + 1u);
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < l; i++)
|
2022-09-08 12:05:56 +02:00
|
|
|
strv[i] = _permission_to_string(&nm_g_array_index(priv->permissions, Permission, i));
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
strv[i] = NULL;
|
|
|
|
|
|
|
|
|
|
g_value_take_boxed(value, strv);
|
2014-07-24 08:53:33 -04:00
|
|
|
break;
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
}
|
2014-07-24 08:53:33 -04:00
|
|
|
case PROP_TIMESTAMP:
|
2019-01-11 08:32:54 +01:00
|
|
|
g_value_set_uint64(value, nm_setting_connection_get_timestamp(setting));
|
2014-07-24 08:53:33 -04:00
|
|
|
break;
|
|
|
|
|
default:
|
2021-10-20 16:13:14 +02:00
|
|
|
_nm_setting_property_get_property_direct(object, prop_id, value, pspec);
|
2014-07-24 08:53:33 -04:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
2019-01-11 08:32:54 +01:00
|
|
|
set_property(GObject *object, guint prop_id, const GValue *value, GParamSpec *pspec)
|
2014-07-24 08:53:33 -04:00
|
|
|
{
|
2019-01-11 08:32:54 +01:00
|
|
|
NMSettingConnectionPrivate *priv = NM_SETTING_CONNECTION_GET_PRIVATE(object);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
switch (prop_id) {
|
|
|
|
|
case PROP_PERMISSIONS:
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
{
|
|
|
|
|
const char *const *strv;
|
|
|
|
|
guint i;
|
|
|
|
|
|
|
|
|
|
nm_clear_pointer(&priv->permissions, g_array_unref);
|
|
|
|
|
strv = g_value_get_boxed(value);
|
|
|
|
|
if (strv && strv[0]) {
|
|
|
|
|
priv->permissions =
|
|
|
|
|
g_array_sized_new(FALSE, FALSE, sizeof(Permission), NM_PTRARRAY_LEN(strv));
|
|
|
|
|
g_array_set_clear_func(priv->permissions, (GDestroyNotify) _permission_clear_stale);
|
|
|
|
|
|
|
|
|
|
for (i = 0; strv[i]; i++) {
|
|
|
|
|
Permission *permission = nm_g_array_append_new(priv->permissions, Permission);
|
|
|
|
|
|
|
|
|
|
_permission_set_stale_parse(permission, strv[i]);
|
|
|
|
|
}
|
|
|
|
|
}
|
2014-07-24 08:53:33 -04:00
|
|
|
break;
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
}
|
2014-07-24 08:53:33 -04:00
|
|
|
case PROP_TIMESTAMP:
|
2019-01-11 08:32:54 +01:00
|
|
|
priv->timestamp = g_value_get_uint64(value);
|
2014-07-24 08:53:33 -04:00
|
|
|
break;
|
|
|
|
|
default:
|
2021-10-20 16:13:14 +02:00
|
|
|
_nm_setting_property_set_property_direct(object, prop_id, value, pspec);
|
2014-07-24 08:53:33 -04:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2019-01-11 08:32:54 +01:00
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
nm_setting_connection_init(NMSettingConnection *setting)
|
2021-10-20 16:13:14 +02:00
|
|
|
{}
|
2019-01-11 08:32:54 +01:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* nm_setting_connection_new:
|
|
|
|
|
*
|
|
|
|
|
* Creates a new #NMSettingConnection object with default values.
|
|
|
|
|
*
|
|
|
|
|
* Returns: the new empty #NMSettingConnection object
|
|
|
|
|
**/
|
|
|
|
|
NMSetting *
|
|
|
|
|
nm_setting_connection_new(void)
|
|
|
|
|
{
|
2020-11-12 15:57:06 +01:00
|
|
|
return g_object_new(NM_TYPE_SETTING_CONNECTION, NULL);
|
2019-01-11 08:32:54 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
finalize(GObject *object)
|
|
|
|
|
{
|
|
|
|
|
NMSettingConnectionPrivate *priv = NM_SETTING_CONNECTION_GET_PRIVATE(object);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
libnm: cleanup handling of "connection.permissions" and improve validation
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
2020-09-24 20:53:13 +02:00
|
|
|
nm_clear_pointer(&priv->permissions, g_array_unref);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2019-01-11 08:32:54 +01:00
|
|
|
G_OBJECT_CLASS(nm_setting_connection_parent_class)->finalize(object);
|
|
|
|
|
}
|
|
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
static void
|
libnm/trivial: cleanup variable names in settings' class-init functions
- Don't use @parent_class name. This local variable (and @object_class) is
the class instance up-cast to the pointer types of the parents. The point
here is not that it is the direct parent. The point is, that it's the
NMSettingClass type.
Also, it can only be used inconsistently, in face of NMSettingIP4Config,
who's parent type is NMSettingIPConfig. Clearly, inside
nm-setting-ip4-config.c we wouldn't want to use the "parent_class"
name. Consistently rename @parent_class to @setting_class.
- Also rename the pointer to the own class to @klass. "setting_class" is also the
wrong name for that, because the right name would be something like
"setting_6lowpan_class".
However, "klass" is preferred over the latter, because we commonly create new
GObject implementations by copying an existing one. Generic names like "klass"
and "self" inside a type implementation make that simpler.
- drop useless comments like
/* virtual functions */
/* Properties */
It's better to logically and visually structure the code, and avoid trival
remarks about that. They only end up being used inconsistently. If you
even need a stronger visual separator, then an 80 char /****/ line
should be preferred.
2018-07-28 10:43:21 +02:00
|
|
|
nm_setting_connection_class_init(NMSettingConnectionClass *klass)
|
2014-07-24 08:53:33 -04:00
|
|
|
{
|
2021-11-09 13:28:54 +01:00
|
|
|
GObjectClass *object_class = G_OBJECT_CLASS(klass);
|
libnm/trivial: cleanup variable names in settings' class-init functions
- Don't use @parent_class name. This local variable (and @object_class) is
the class instance up-cast to the pointer types of the parents. The point
here is not that it is the direct parent. The point is, that it's the
NMSettingClass type.
Also, it can only be used inconsistently, in face of NMSettingIP4Config,
who's parent type is NMSettingIPConfig. Clearly, inside
nm-setting-ip4-config.c we wouldn't want to use the "parent_class"
name. Consistently rename @parent_class to @setting_class.
- Also rename the pointer to the own class to @klass. "setting_class" is also the
wrong name for that, because the right name would be something like
"setting_6lowpan_class".
However, "klass" is preferred over the latter, because we commonly create new
GObject implementations by copying an existing one. Generic names like "klass"
and "self" inside a type implementation make that simpler.
- drop useless comments like
/* virtual functions */
/* Properties */
It's better to logically and visually structure the code, and avoid trival
remarks about that. They only end up being used inconsistently. If you
even need a stronger visual separator, then an 80 char /****/ line
should be preferred.
2018-07-28 10:43:21 +02:00
|
|
|
NMSettingClass *setting_class = NM_SETTING_CLASS(klass);
|
2023-10-25 16:10:06 +02:00
|
|
|
GArray *properties_override = _nm_sett_info_property_override_create_array_sized(35);
|
2014-07-24 08:53:33 -04:00
|
|
|
|
|
|
|
|
object_class->get_property = get_property;
|
2019-01-11 08:32:54 +01:00
|
|
|
object_class->set_property = set_property;
|
2014-07-24 08:53:33 -04:00
|
|
|
object_class->finalize = finalize;
|
|
|
|
|
|
2021-06-29 14:37:16 +02:00
|
|
|
setting_class->verify = verify;
|
2014-07-24 08:53:33 -04:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* NMSettingConnection:id:
|
|
|
|
|
*
|
|
|
|
|
* A human readable unique identifier for the connection, like "Work Wi-Fi"
|
|
|
|
|
* or "T-Mobile 3G".
|
|
|
|
|
**/
|
libnm, libnm-util: move settings doc generation to libnm-core
Move the settings/plugins doc generation from libnm-util to
libnm-core, since libnm-util isn't being updated for all new
properties.
With this commit, the keyfile and ifcfg-rh documentation is basically
unchanged, except that deprecated properties are now gone, and new
properties have been added, and the sections are in a different order.
(generate-plugin-docs.pl just outputs the settings in Makefile order,
and they were unsorted in libnm-util, but are sorted in libnm-core).
The settings documentation used for nm-settings.5, the D-Bus API docs,
and the nmcli help is changed a bit more at this point, and mostly for
the worse, since the libnm-core setting properties don't match up with
the D-Bus API as well as the libnm-util ones do. To be fixed...
(I also removed the "plugins docs" line in each plugin docs comment
block while moving them, since those blocks will be used for more than
just plugins soon, and it's sort of obvious anyway.)
2014-10-28 09:58:25 -04:00
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: id
|
|
|
|
|
* variable: NAME(+)
|
|
|
|
|
* description: User friendly name for the connection profile.
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
2021-06-29 14:37:16 +02:00
|
|
|
_nm_setting_property_define_direct_string_full(
|
|
|
|
|
properties_override,
|
|
|
|
|
obj_properties,
|
|
|
|
|
NM_SETTING_CONNECTION_ID,
|
|
|
|
|
PROP_ID,
|
|
|
|
|
NM_SETTING_PARAM_FUZZY_IGNORE,
|
|
|
|
|
NM_SETT_INFO_PROPERT_TYPE_DBUS(G_VARIANT_TYPE_STRING,
|
2021-06-30 00:05:49 +02:00
|
|
|
.direct_type = NM_VALUE_TYPE_STRING,
|
|
|
|
|
.compare_fcn = compare_fcn_id,
|
|
|
|
|
.to_dbus_fcn = _nm_setting_property_to_dbus_fcn_direct,
|
2021-07-14 15:48:37 +02:00
|
|
|
.from_dbus_fcn = _nm_setting_property_from_dbus_fcn_direct,
|
|
|
|
|
.from_dbus_is_full = TRUE,
|
|
|
|
|
.from_dbus_direct_allow_transform = TRUE),
|
2021-06-29 14:37:16 +02:00
|
|
|
NMSettingConnectionPrivate,
|
|
|
|
|
id);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
/**
|
|
|
|
|
* NMSettingConnection:uuid:
|
|
|
|
|
*
|
|
|
|
|
* A universally unique identifier for the connection, for example generated
|
|
|
|
|
* with libuuid. It should be assigned when the connection is created, and
|
|
|
|
|
* never changed as long as the connection still applies to the same
|
|
|
|
|
* network. For example, it should not be changed when the
|
|
|
|
|
* #NMSettingConnection:id property or #NMSettingIP4Config changes, but
|
|
|
|
|
* might need to be re-created when the Wi-Fi SSID, mobile broadband network
|
|
|
|
|
* provider, or #NMSettingConnection:type property changes.
|
|
|
|
|
*
|
|
|
|
|
* The UUID must be in the format "2815492f-7e56-435e-b2e9-246bd7cdc664"
|
|
|
|
|
* (ie, contains only hexadecimal characters and "-"). A suitable UUID may
|
|
|
|
|
* be generated by nm_utils_uuid_generate() or
|
2021-05-02 21:32:31 +02:00
|
|
|
* nm_uuid_generate_from_string_str().
|
2014-07-24 08:53:33 -04:00
|
|
|
**/
|
2022-08-26 10:29:15 +02:00
|
|
|
/* ---nmcli---
|
|
|
|
|
* property: uuid
|
|
|
|
|
* format: a valid RFC4122 universally unique identifier (UUID).
|
|
|
|
|
* description: The connection.uuid is the real identifier of a profile.
|
|
|
|
|
* It cannot change and it must be unique. It is therefore often best
|
|
|
|
|
* to refer to a profile by UUID, for example with `nmcli connection up uuid $UUID`.
|
|
|
|
|
*
|
|
|
|
|
* The UUID cannot be changed, except in offline mode. In that case,
|
|
|
|
|
* the special values "new", "generate" and "" are allowed to generate
|
|
|
|
|
* a new random UUID.
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
libnm, libnm-util: move settings doc generation to libnm-core
Move the settings/plugins doc generation from libnm-util to
libnm-core, since libnm-util isn't being updated for all new
properties.
With this commit, the keyfile and ifcfg-rh documentation is basically
unchanged, except that deprecated properties are now gone, and new
properties have been added, and the sections are in a different order.
(generate-plugin-docs.pl just outputs the settings in Makefile order,
and they were unsorted in libnm-util, but are sorted in libnm-core).
The settings documentation used for nm-settings.5, the D-Bus API docs,
and the nmcli help is changed a bit more at this point, and mostly for
the worse, since the libnm-core setting properties don't match up with
the D-Bus API as well as the libnm-util ones do. To be fixed...
(I also removed the "plugins docs" line in each plugin docs comment
block while moving them, since those blocks will be used for more than
just plugins soon, and it's sort of obvious anyway.)
2014-10-28 09:58:25 -04:00
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: uuid
|
|
|
|
|
* variable: UUID(+)
|
2014-11-20 13:18:32 +01:00
|
|
|
* description: UUID for the connection profile. When missing, NetworkManager
|
2016-06-21 16:41:05 +02:00
|
|
|
* creates the UUID itself (by hashing the filename).
|
libnm, libnm-util: move settings doc generation to libnm-core
Move the settings/plugins doc generation from libnm-util to
libnm-core, since libnm-util isn't being updated for all new
properties.
With this commit, the keyfile and ifcfg-rh documentation is basically
unchanged, except that deprecated properties are now gone, and new
properties have been added, and the sections are in a different order.
(generate-plugin-docs.pl just outputs the settings in Makefile order,
and they were unsorted in libnm-util, but are sorted in libnm-core).
The settings documentation used for nm-settings.5, the D-Bus API docs,
and the nmcli help is changed a bit more at this point, and mostly for
the worse, since the libnm-core setting properties don't match up with
the D-Bus API as well as the libnm-util ones do. To be fixed...
(I also removed the "plugins docs" line in each plugin docs comment
block while moving them, since those blocks will be used for more than
just plugins soon, and it's sort of obvious anyway.)
2014-10-28 09:58:25 -04:00
|
|
|
* ---end---
|
|
|
|
|
*/
|
2021-06-28 17:28:21 +02:00
|
|
|
_nm_setting_property_define_direct_string(properties_override,
|
|
|
|
|
obj_properties,
|
|
|
|
|
NM_SETTING_CONNECTION_UUID,
|
|
|
|
|
PROP_UUID,
|
|
|
|
|
NM_SETTING_PARAM_FUZZY_IGNORE,
|
|
|
|
|
NMSettingConnectionPrivate,
|
|
|
|
|
uuid);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2016-06-21 16:41:05 +02:00
|
|
|
/**
|
|
|
|
|
* NMSettingConnection:stable-id:
|
|
|
|
|
*
|
2018-05-22 18:35:43 +02:00
|
|
|
* This represents the identity of the connection used for various purposes.
|
|
|
|
|
* It allows to configure multiple profiles to share the identity. Also,
|
|
|
|
|
* the stable-id can contain placeholders that are substituted dynamically and
|
|
|
|
|
* deterministically depending on the context.
|
2016-06-21 16:41:05 +02:00
|
|
|
*
|
2023-03-08 08:58:42 +01:00
|
|
|
* The stable-id is used for generating IPv6 stable private addresses with
|
|
|
|
|
* ipv6.addr-gen-mode=stable-privacy. It is also used to seed the generated
|
|
|
|
|
* cloned MAC address for ethernet.cloned-mac-address=stable and
|
|
|
|
|
* wifi.cloned-mac-address=stable. It is also used to derive the DHCP
|
|
|
|
|
* client identifier with ipv4.dhcp-client-id=stable, the DHCPv6 DUID with
|
|
|
|
|
* ipv6.dhcp-duid=stable-[llt,ll,uuid] and the DHCP IAID with
|
|
|
|
|
* ipv4.iaid=stable and ipv6.iaid=stable.
|
2018-02-14 17:01:56 +01:00
|
|
|
*
|
2018-05-22 18:35:43 +02:00
|
|
|
* Note that depending on the context where it is used, other parameters are
|
|
|
|
|
* also seeded into the generation algorithm. For example, a per-host key
|
|
|
|
|
* is commonly also included, so that different systems end up generating
|
|
|
|
|
* different IDs. Or with ipv6.addr-gen-mode=stable-privacy, also the device's
|
|
|
|
|
* name is included, so that different interfaces yield different addresses.
|
2022-03-11 09:06:19 +01:00
|
|
|
* The per-host key is the identity of your machine and stored in /var/lib/NetworkManager/secret_key.
|
|
|
|
|
* See NetworkManager(8) manual about the secret-key and the host identity.
|
2016-12-18 13:54:26 +01:00
|
|
|
*
|
libnm,core: make "default${CONNECTION}" the built-in stable ID
The "connection.stable-id" supports placeholders like "${CONNECTION}" or
"${DEVICE}".
The stable-id can also be specified in global connection defaults in
NetworkManager.conf, by leaving it unset in the profile. Global
connection defaults always follow the pattern, that they correspond to a
per-profile property, and only when the per-profile value indicates a
special default/unset value, the global connection default is consulted.
Finally, if the global connection default is also not configured in
NetworkManager.conf, a built-in default is used (which may not be
constant either, for example ipv6.ip6-privacy's built-in default depends
on a sysctl value).
In any case, every possible configuration that can be achieved should be
configurable both per-profile and via global connection default. That
was not given for the stable-id, because the built-in default generated
an ID in a way that could not be explicitly expressed otherwise.
So you could not:
- explicitly set the per-profile value to the built-in default, to avoid
that the global-connection-default overwrites it.
- explicitly set the global-connection-default to the built-in default,
to avoid that a lower priority [connection*] section overwrites the
stable-id again.
Fix that inconsistency to make it possible to explicitly set the
built-in default.
Change behavior for literally "default${CONNECTION}" and make it behave
as the built-in default. Also document that the built-in default has that
value.
It's unlikely that this breaks an existing configuration, but of course,
if any user configured "connection.stable-id=default${CONNECTION}", then
the behavior changes for them.
2023-04-18 13:49:19 +02:00
|
|
|
* The '$' character is treated special to perform dynamic substitutions at
|
|
|
|
|
* activation time. Currently, supported are "${CONNECTION}", "${DEVICE}",
|
|
|
|
|
* "${MAC}", "${BOOT}", "${RANDOM}". These effectively create unique IDs
|
|
|
|
|
* per-connection, per-device, per-boot, or every time. The "${CONNECTION}"
|
|
|
|
|
* uses the profile's connection.uuid, the "${DEVICE}" uses the interface
|
|
|
|
|
* name of the device and "${MAC}" the permanent MAC address of the device.
|
2016-12-18 13:54:26 +01:00
|
|
|
* Any unrecognized patterns following '$' are treated verbatim, however
|
libnm,core: make "default${CONNECTION}" the built-in stable ID
The "connection.stable-id" supports placeholders like "${CONNECTION}" or
"${DEVICE}".
The stable-id can also be specified in global connection defaults in
NetworkManager.conf, by leaving it unset in the profile. Global
connection defaults always follow the pattern, that they correspond to a
per-profile property, and only when the per-profile value indicates a
special default/unset value, the global connection default is consulted.
Finally, if the global connection default is also not configured in
NetworkManager.conf, a built-in default is used (which may not be
constant either, for example ipv6.ip6-privacy's built-in default depends
on a sysctl value).
In any case, every possible configuration that can be achieved should be
configurable both per-profile and via global connection default. That
was not given for the stable-id, because the built-in default generated
an ID in a way that could not be explicitly expressed otherwise.
So you could not:
- explicitly set the per-profile value to the built-in default, to avoid
that the global-connection-default overwrites it.
- explicitly set the global-connection-default to the built-in default,
to avoid that a lower priority [connection*] section overwrites the
stable-id again.
Fix that inconsistency to make it possible to explicitly set the
built-in default.
Change behavior for literally "default${CONNECTION}" and make it behave
as the built-in default. Also document that the built-in default has that
value.
It's unlikely that this breaks an existing configuration, but of course,
if any user configured "connection.stable-id=default${CONNECTION}", then
the behavior changes for them.
2023-04-18 13:49:19 +02:00
|
|
|
* are reserved for future use. You are thus advised to avoid '$' or escape
|
|
|
|
|
* it as "$$". For example, set it to "${CONNECTION}-${BOOT}-${DEVICE}" to
|
|
|
|
|
* create a unique id for this connection that changes with every reboot
|
|
|
|
|
* and differs depending on the interface where the profile activates.
|
2016-12-18 13:54:26 +01:00
|
|
|
*
|
2018-05-22 18:35:43 +02:00
|
|
|
* If the value is unset, a global connection default is consulted. If the
|
libnm,core: make "default${CONNECTION}" the built-in stable ID
The "connection.stable-id" supports placeholders like "${CONNECTION}" or
"${DEVICE}".
The stable-id can also be specified in global connection defaults in
NetworkManager.conf, by leaving it unset in the profile. Global
connection defaults always follow the pattern, that they correspond to a
per-profile property, and only when the per-profile value indicates a
special default/unset value, the global connection default is consulted.
Finally, if the global connection default is also not configured in
NetworkManager.conf, a built-in default is used (which may not be
constant either, for example ipv6.ip6-privacy's built-in default depends
on a sysctl value).
In any case, every possible configuration that can be achieved should be
configurable both per-profile and via global connection default. That
was not given for the stable-id, because the built-in default generated
an ID in a way that could not be explicitly expressed otherwise.
So you could not:
- explicitly set the per-profile value to the built-in default, to avoid
that the global-connection-default overwrites it.
- explicitly set the global-connection-default to the built-in default,
to avoid that a lower priority [connection*] section overwrites the
stable-id again.
Fix that inconsistency to make it possible to explicitly set the
built-in default.
Change behavior for literally "default${CONNECTION}" and make it behave
as the built-in default. Also document that the built-in default has that
value.
It's unlikely that this breaks an existing configuration, but of course,
if any user configured "connection.stable-id=default${CONNECTION}", then
the behavior changes for them.
2023-04-18 13:49:19 +02:00
|
|
|
* value is still unset, the default is "default${CONNECTION}" go generate
|
|
|
|
|
* an ID unique per connection profile.
|
2016-06-21 18:07:56 +02:00
|
|
|
*
|
2016-06-21 16:41:05 +02:00
|
|
|
* Since: 1.4
|
|
|
|
|
**/
|
|
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: stable-id
|
|
|
|
|
* variable: STABLE_ID(+)
|
|
|
|
|
* description: Token to generate stable IDs.
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
2021-06-28 19:17:19 +02:00
|
|
|
_nm_setting_property_define_direct_string(properties_override,
|
|
|
|
|
obj_properties,
|
|
|
|
|
NM_SETTING_CONNECTION_STABLE_ID,
|
|
|
|
|
PROP_STABLE_ID,
|
|
|
|
|
NM_SETTING_PARAM_FUZZY_IGNORE,
|
|
|
|
|
NMSettingConnectionPrivate,
|
|
|
|
|
stable_id);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
/**
|
|
|
|
|
* NMSettingConnection:interface-name:
|
|
|
|
|
*
|
|
|
|
|
* The name of the network interface this connection is bound to. If not
|
|
|
|
|
* set, then the connection can be attached to any interface of the
|
|
|
|
|
* appropriate type (subject to restrictions imposed by other settings).
|
|
|
|
|
*
|
|
|
|
|
* For software devices this specifies the name of the created device.
|
|
|
|
|
*
|
|
|
|
|
* For connection types where interface names cannot easily be made
|
|
|
|
|
* persistent (e.g. mobile broadband or USB Ethernet), this property should
|
|
|
|
|
* not be used. Setting this property restricts the interfaces a connection
|
|
|
|
|
* can be used with, and if interface names change or are reordered the
|
|
|
|
|
* connection may be applied to the wrong interface.
|
|
|
|
|
**/
|
libnm, libnm-util: move settings doc generation to libnm-core
Move the settings/plugins doc generation from libnm-util to
libnm-core, since libnm-util isn't being updated for all new
properties.
With this commit, the keyfile and ifcfg-rh documentation is basically
unchanged, except that deprecated properties are now gone, and new
properties have been added, and the sections are in a different order.
(generate-plugin-docs.pl just outputs the settings in Makefile order,
and they were unsorted in libnm-util, but are sorted in libnm-core).
The settings documentation used for nm-settings.5, the D-Bus API docs,
and the nmcli help is changed a bit more at this point, and mostly for
the worse, since the libnm-core setting properties don't match up with
the D-Bus API as well as the libnm-util ones do. To be fixed...
(I also removed the "plugins docs" line in each plugin docs comment
block while moving them, since those blocks will be used for more than
just plugins soon, and it's sort of obvious anyway.)
2014-10-28 09:58:25 -04:00
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: interface-name
|
|
|
|
|
* variable: DEVICE
|
|
|
|
|
* description: Interface name of the device this profile is bound to. The variable
|
|
|
|
|
* can be left out when the profile should apply for more devices. Note that DEVICE
|
|
|
|
|
* can be required for some connection types.
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
2021-06-28 17:28:21 +02:00
|
|
|
_nm_setting_property_define_direct_string_full(
|
2019-09-22 15:32:04 +02:00
|
|
|
properties_override,
|
2021-06-17 22:53:52 +02:00
|
|
|
obj_properties,
|
|
|
|
|
NM_SETTING_CONNECTION_INTERFACE_NAME,
|
|
|
|
|
PROP_INTERFACE_NAME,
|
|
|
|
|
NM_SETTING_PARAM_INFERRABLE,
|
|
|
|
|
NM_SETT_INFO_PROPERT_TYPE_DBUS(G_VARIANT_TYPE_STRING,
|
2021-06-28 17:28:21 +02:00
|
|
|
.direct_type = NM_VALUE_TYPE_STRING,
|
2021-06-29 18:18:06 +02:00
|
|
|
.compare_fcn = _nm_setting_property_compare_fcn_direct,
|
2021-06-28 17:28:21 +02:00
|
|
|
.to_dbus_fcn = _nm_setting_property_to_dbus_fcn_direct,
|
2021-06-17 22:53:52 +02:00
|
|
|
.missing_from_dbus_fcn =
|
2021-06-30 00:05:49 +02:00
|
|
|
nm_setting_connection_no_interface_name,
|
2021-07-14 15:48:37 +02:00
|
|
|
.from_dbus_fcn = _nm_setting_property_from_dbus_fcn_direct,
|
|
|
|
|
.from_dbus_is_full = TRUE,
|
|
|
|
|
.from_dbus_direct_allow_transform = TRUE),
|
2021-06-28 17:28:21 +02:00
|
|
|
NMSettingConnectionPrivate,
|
|
|
|
|
interface_name);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
/**
|
|
|
|
|
* NMSettingConnection:type:
|
|
|
|
|
*
|
|
|
|
|
* Base type of the connection. For hardware-dependent connections, should
|
|
|
|
|
* contain the setting name of the hardware-type specific setting (ie,
|
|
|
|
|
* "802-3-ethernet" or "802-11-wireless" or "bluetooth", etc), and for
|
|
|
|
|
* non-hardware dependent connections like VPN or otherwise, should contain
|
|
|
|
|
* the setting name of that setting type (ie, "vpn" or "bridge", etc).
|
|
|
|
|
**/
|
libnm, libnm-util: move settings doc generation to libnm-core
Move the settings/plugins doc generation from libnm-util to
libnm-core, since libnm-util isn't being updated for all new
properties.
With this commit, the keyfile and ifcfg-rh documentation is basically
unchanged, except that deprecated properties are now gone, and new
properties have been added, and the sections are in a different order.
(generate-plugin-docs.pl just outputs the settings in Makefile order,
and they were unsorted in libnm-util, but are sorted in libnm-core).
The settings documentation used for nm-settings.5, the D-Bus API docs,
and the nmcli help is changed a bit more at this point, and mostly for
the worse, since the libnm-core setting properties don't match up with
the D-Bus API as well as the libnm-util ones do. To be fixed...
(I also removed the "plugins docs" line in each plugin docs comment
block while moving them, since those blocks will be used for more than
just plugins soon, and it's sort of obvious anyway.)
2014-10-28 09:58:25 -04:00
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: type
|
|
|
|
|
* variable: TYPE (DEVICETYPE, DEVICE)
|
|
|
|
|
* values: Ethernet, Wireless, InfiniBand, Bridge, Bond, Vlan, Team, TeamPort
|
|
|
|
|
* description: Base type of the connection. DEVICETYPE is used for teaming
|
|
|
|
|
* connections.
|
|
|
|
|
* example: TYPE=Ethernet; TYPE=Bond; TYPE=Bridge; DEVICETYPE=TeamPort
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
2021-06-28 17:28:21 +02:00
|
|
|
_nm_setting_property_define_direct_string(properties_override,
|
|
|
|
|
obj_properties,
|
|
|
|
|
NM_SETTING_CONNECTION_TYPE,
|
|
|
|
|
PROP_TYPE,
|
|
|
|
|
NM_SETTING_PARAM_INFERRABLE,
|
|
|
|
|
NMSettingConnectionPrivate,
|
2022-01-05 17:05:00 +01:00
|
|
|
type,
|
|
|
|
|
.direct_string_is_refstr = TRUE);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
/**
|
|
|
|
|
* NMSettingConnection:permissions:
|
|
|
|
|
*
|
|
|
|
|
* An array of strings defining what access a given user has to this
|
|
|
|
|
* connection. If this is %NULL or empty, all users are allowed to access
|
2017-07-19 16:24:07 +02:00
|
|
|
* this connection; otherwise users are allowed if and only if they are in
|
|
|
|
|
* this list. When this is not empty, the connection can be active only when
|
|
|
|
|
* one of the specified users is logged into an active session. Each entry
|
|
|
|
|
* is of the form "[type]:[id]:[reserved]"; for example, "user:dcbw:blah".
|
2014-07-24 08:53:33 -04:00
|
|
|
*
|
|
|
|
|
* At this time only the "user" [type] is allowed. Any other values are
|
|
|
|
|
* ignored and reserved for future use. [id] is the username that this
|
|
|
|
|
* permission refers to, which may not contain the ":" character. Any
|
|
|
|
|
* [reserved] information present must be ignored and is reserved for future
|
|
|
|
|
* use. All of [type], [id], and [reserved] must be valid UTF-8.
|
|
|
|
|
*/
|
libnm, libnm-util: move settings doc generation to libnm-core
Move the settings/plugins doc generation from libnm-util to
libnm-core, since libnm-util isn't being updated for all new
properties.
With this commit, the keyfile and ifcfg-rh documentation is basically
unchanged, except that deprecated properties are now gone, and new
properties have been added, and the sections are in a different order.
(generate-plugin-docs.pl just outputs the settings in Makefile order,
and they were unsorted in libnm-util, but are sorted in libnm-core).
The settings documentation used for nm-settings.5, the D-Bus API docs,
and the nmcli help is changed a bit more at this point, and mostly for
the worse, since the libnm-core setting properties don't match up with
the D-Bus API as well as the libnm-util ones do. To be fixed...
(I also removed the "plugins docs" line in each plugin docs comment
block while moving them, since those blocks will be used for more than
just plugins soon, and it's sort of obvious anyway.)
2014-10-28 09:58:25 -04:00
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: permissions
|
|
|
|
|
* variable: USERS(+)
|
2017-07-19 16:24:07 +02:00
|
|
|
* description: Restrict to certain users the access to this connection, and
|
|
|
|
|
* allow the connection to be active only when at least one of the
|
|
|
|
|
* specified users is logged into an active session.
|
libnm, libnm-util: move settings doc generation to libnm-core
Move the settings/plugins doc generation from libnm-util to
libnm-core, since libnm-util isn't being updated for all new
properties.
With this commit, the keyfile and ifcfg-rh documentation is basically
unchanged, except that deprecated properties are now gone, and new
properties have been added, and the sections are in a different order.
(generate-plugin-docs.pl just outputs the settings in Makefile order,
and they were unsorted in libnm-util, but are sorted in libnm-core).
The settings documentation used for nm-settings.5, the D-Bus API docs,
and the nmcli help is changed a bit more at this point, and mostly for
the worse, since the libnm-core setting properties don't match up with
the D-Bus API as well as the libnm-util ones do. To be fixed...
(I also removed the "plugins docs" line in each plugin docs comment
block while moving them, since those blocks will be used for more than
just plugins soon, and it's sort of obvious anyway.)
2014-10-28 09:58:25 -04:00
|
|
|
* example: USERS="joe bob"
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
2023-10-25 13:17:37 +02:00
|
|
|
_nm_setting_property_define_gprop_strv_oldstyle(properties_override,
|
|
|
|
|
obj_properties,
|
|
|
|
|
NM_SETTING_CONNECTION_PERMISSIONS,
|
|
|
|
|
PROP_PERMISSIONS,
|
|
|
|
|
NM_SETTING_PARAM_NONE);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
/**
|
|
|
|
|
* NMSettingConnection:autoconnect:
|
|
|
|
|
*
|
|
|
|
|
* Whether or not the connection should be automatically connected by
|
|
|
|
|
* NetworkManager when the resources for the connection are available.
|
|
|
|
|
* %TRUE to automatically activate the connection, %FALSE to require manual
|
|
|
|
|
* intervention to activate the connection.
|
2018-04-12 11:44:58 +02:00
|
|
|
*
|
2021-06-22 12:11:07 +02:00
|
|
|
* Autoconnect happens when the circumstances are suitable. That means for
|
|
|
|
|
* example that the device is currently managed and not active. Autoconnect
|
|
|
|
|
* thus never replaces or competes with an already active profile.
|
|
|
|
|
*
|
2018-04-12 11:44:58 +02:00
|
|
|
* Note that autoconnect is not implemented for VPN profiles. See
|
|
|
|
|
* #NMSettingConnection:secondaries as an alternative to automatically
|
|
|
|
|
* connect VPN profiles.
|
2022-03-16 09:59:54 +01:00
|
|
|
*
|
|
|
|
|
* If multiple profiles are ready to autoconnect on the same device,
|
|
|
|
|
* the one with the better "connection.autoconnect-priority" is chosen. If
|
|
|
|
|
* the priorities are equal, then the most recently connected profile is activated.
|
|
|
|
|
* If the profiles were not connected earlier or their
|
|
|
|
|
* "connection.timestamp" is identical, the choice is undefined.
|
|
|
|
|
*
|
|
|
|
|
* Depending on "connection.multi-connect", a profile can (auto)connect only
|
|
|
|
|
* once at a time or multiple times.
|
2014-07-24 08:53:33 -04:00
|
|
|
**/
|
libnm, libnm-util: move settings doc generation to libnm-core
Move the settings/plugins doc generation from libnm-util to
libnm-core, since libnm-util isn't being updated for all new
properties.
With this commit, the keyfile and ifcfg-rh documentation is basically
unchanged, except that deprecated properties are now gone, and new
properties have been added, and the sections are in a different order.
(generate-plugin-docs.pl just outputs the settings in Makefile order,
and they were unsorted in libnm-util, but are sorted in libnm-core).
The settings documentation used for nm-settings.5, the D-Bus API docs,
and the nmcli help is changed a bit more at this point, and mostly for
the worse, since the libnm-core setting properties don't match up with
the D-Bus API as well as the libnm-util ones do. To be fixed...
(I also removed the "plugins docs" line in each plugin docs comment
block while moving them, since those blocks will be used for more than
just plugins soon, and it's sort of obvious anyway.)
2014-10-28 09:58:25 -04:00
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: autoconnect
|
|
|
|
|
* variable: ONBOOT
|
|
|
|
|
* default: yes
|
|
|
|
|
* description: Whether the connection should be autoconnected (not only while booting).
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
2021-06-28 17:04:37 +02:00
|
|
|
_nm_setting_property_define_direct_boolean(properties_override,
|
|
|
|
|
obj_properties,
|
|
|
|
|
NM_SETTING_CONNECTION_AUTOCONNECT,
|
|
|
|
|
PROP_AUTOCONNECT,
|
|
|
|
|
TRUE,
|
|
|
|
|
NM_SETTING_PARAM_FUZZY_IGNORE,
|
|
|
|
|
NMSettingConnectionPrivate,
|
|
|
|
|
autoconnect);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-08-25 20:39:40 +02:00
|
|
|
/**
|
|
|
|
|
* NMSettingConnection:autoconnect-priority:
|
|
|
|
|
*
|
2021-06-22 12:11:07 +02:00
|
|
|
* The autoconnect priority in range -999 to 999. If the connection is set
|
|
|
|
|
* to autoconnect, connections with higher priority will be preferred.
|
|
|
|
|
* The higher number means higher priority. Defaults to 0.
|
|
|
|
|
* Note that this property only matters if there are more than one candidate
|
|
|
|
|
* profile to select for autoconnect. In case of equal priority, the profile
|
|
|
|
|
* used most recently is chosen.
|
2014-08-25 20:39:40 +02:00
|
|
|
**/
|
2014-11-19 09:42:22 +01:00
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: autoconnect-priority
|
|
|
|
|
* variable: AUTOCONNECT_PRIORITY(+)
|
|
|
|
|
* values: -999 to 999
|
|
|
|
|
* default: 0
|
|
|
|
|
* description: Connection priority for automatic activation. Connections with
|
|
|
|
|
* higher numbers are preferred when selecting profiles for automatic activation.
|
|
|
|
|
* example: AUTOCONNECT_PRIORITY=20
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
2021-07-13 17:37:08 +02:00
|
|
|
_nm_setting_property_define_direct_int32(properties_override,
|
|
|
|
|
obj_properties,
|
|
|
|
|
NM_SETTING_CONNECTION_AUTOCONNECT_PRIORITY,
|
|
|
|
|
PROP_AUTOCONNECT_PRIORITY,
|
|
|
|
|
NM_SETTING_CONNECTION_AUTOCONNECT_PRIORITY_MIN,
|
|
|
|
|
NM_SETTING_CONNECTION_AUTOCONNECT_PRIORITY_MAX,
|
|
|
|
|
NM_SETTING_CONNECTION_AUTOCONNECT_PRIORITY_DEFAULT,
|
|
|
|
|
NM_SETTING_PARAM_FUZZY_IGNORE,
|
|
|
|
|
NMSettingConnectionPrivate,
|
|
|
|
|
autoconnect_priority);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2016-10-08 10:27:15 +02:00
|
|
|
/**
|
|
|
|
|
* NMSettingConnection:autoconnect-retries:
|
|
|
|
|
*
|
2017-05-28 17:34:31 +03:00
|
|
|
* The number of times a connection should be tried when autoactivating before
|
2016-10-08 10:27:15 +02:00
|
|
|
* giving up. Zero means forever, -1 means the global default (4 times if not
|
2017-10-24 09:34:35 +02:00
|
|
|
* overridden). Setting this to 1 means to try activation only once before
|
|
|
|
|
* blocking autoconnect. Note that after a timeout, NetworkManager will try
|
|
|
|
|
* to autoconnect again.
|
2016-10-08 10:27:15 +02:00
|
|
|
*/
|
2016-10-08 10:27:21 +02:00
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: autoconnect-retries
|
|
|
|
|
* variable: AUTOCONNECT_RETRIES(+)
|
|
|
|
|
* description: The number of times a connection should be autoactivated
|
|
|
|
|
* before giving up and switching to the next one.
|
|
|
|
|
* values: -1 (use global default), 0 (forever) or a positive value
|
|
|
|
|
* example: AUTOCONNECT_RETRIES=1
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
2021-07-13 17:37:08 +02:00
|
|
|
_nm_setting_property_define_direct_int32(properties_override,
|
|
|
|
|
obj_properties,
|
|
|
|
|
NM_SETTING_CONNECTION_AUTOCONNECT_RETRIES,
|
|
|
|
|
PROP_AUTOCONNECT_RETRIES,
|
|
|
|
|
-1,
|
|
|
|
|
G_MAXINT32,
|
|
|
|
|
-1,
|
|
|
|
|
NM_SETTING_PARAM_FUZZY_IGNORE,
|
|
|
|
|
NMSettingConnectionPrivate,
|
|
|
|
|
autoconnect_retries);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
all: add connection.multi-connect property for wildcard profiles
Add a new option that allows to activate a profile multiple times
(at the same time). Previoulsy, all profiles were implicitly
NM_SETTING_CONNECTION_MULTI_CONNECT_SINGLE, meaning, that activating
a profile that is already active will deactivate it first.
This will make more sense, as we also add more match-options how
profiles can be restricted to particular devices. We already have
connection.type, connection.interface-name, and (ethernet|wifi).mac-address
to restrict a profile to particular devices. For example, it is however
not possible to specify a wildcard like "eth*" to match a profile to
a set of devices by interface-name. That is another missing feature,
and once we extend the matching capabilities, it makes more sense to
activate a profile multiple times.
See also https://bugzilla.redhat.com/show_bug.cgi?id=997998, which
previously changed that a connection is restricted to a single activation
at a time. This work relaxes that again.
This only adds the new property, it is not used nor implemented yet.
https://bugzilla.redhat.com/show_bug.cgi?id=1555012
2018-04-10 11:45:35 +02:00
|
|
|
/**
|
|
|
|
|
* NMSettingConnection:multi-connect:
|
|
|
|
|
*
|
|
|
|
|
* Specifies whether the profile can be active multiple times at a particular
|
|
|
|
|
* moment. The value is of type #NMConnectionMultiConnect.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.14
|
|
|
|
|
*/
|
|
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: multi-connect
|
|
|
|
|
* variable: MULTI_CONNECT(+)
|
|
|
|
|
* description: whether the profile can be active on multiple devices at a given
|
|
|
|
|
* moment. The values are numbers corresponding to #NMConnectionMultiConnect enum.
|
2020-02-14 13:25:37 +01:00
|
|
|
* example: MULTI_CONNECT=3
|
all: add connection.multi-connect property for wildcard profiles
Add a new option that allows to activate a profile multiple times
(at the same time). Previoulsy, all profiles were implicitly
NM_SETTING_CONNECTION_MULTI_CONNECT_SINGLE, meaning, that activating
a profile that is already active will deactivate it first.
This will make more sense, as we also add more match-options how
profiles can be restricted to particular devices. We already have
connection.type, connection.interface-name, and (ethernet|wifi).mac-address
to restrict a profile to particular devices. For example, it is however
not possible to specify a wildcard like "eth*" to match a profile to
a set of devices by interface-name. That is another missing feature,
and once we extend the matching capabilities, it makes more sense to
activate a profile multiple times.
See also https://bugzilla.redhat.com/show_bug.cgi?id=997998, which
previously changed that a connection is restricted to a single activation
at a time. This work relaxes that again.
This only adds the new property, it is not used nor implemented yet.
https://bugzilla.redhat.com/show_bug.cgi?id=1555012
2018-04-10 11:45:35 +02:00
|
|
|
* ---end---
|
|
|
|
|
*/
|
2021-07-13 17:37:08 +02:00
|
|
|
_nm_setting_property_define_direct_int32(properties_override,
|
|
|
|
|
obj_properties,
|
|
|
|
|
NM_SETTING_CONNECTION_MULTI_CONNECT,
|
|
|
|
|
PROP_MULTI_CONNECT,
|
|
|
|
|
G_MININT32,
|
|
|
|
|
G_MAXINT32,
|
|
|
|
|
NM_CONNECTION_MULTI_CONNECT_DEFAULT,
|
|
|
|
|
NM_SETTING_PARAM_FUZZY_IGNORE,
|
|
|
|
|
NMSettingConnectionPrivate,
|
|
|
|
|
multi_connect);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
/**
|
|
|
|
|
* NMSettingConnection:timestamp:
|
|
|
|
|
*
|
|
|
|
|
* The time, in seconds since the Unix Epoch, that the connection was last
|
|
|
|
|
* _successfully_ fully activated.
|
|
|
|
|
*
|
|
|
|
|
* NetworkManager updates the connection timestamp periodically when the
|
|
|
|
|
* connection is active to ensure that an active connection has the latest
|
|
|
|
|
* timestamp. The property is only meant for reading (changes to this
|
|
|
|
|
* property will not be preserved).
|
|
|
|
|
**/
|
2019-01-11 08:28:26 +01:00
|
|
|
obj_properties[PROP_TIMESTAMP] = g_param_spec_uint64(
|
|
|
|
|
NM_SETTING_CONNECTION_TIMESTAMP,
|
|
|
|
|
"",
|
|
|
|
|
"",
|
|
|
|
|
0,
|
|
|
|
|
G_MAXUINT64,
|
|
|
|
|
0,
|
|
|
|
|
G_PARAM_READWRITE | NM_SETTING_PARAM_FUZZY_IGNORE | G_PARAM_STATIC_STRINGS);
|
2019-09-22 15:32:04 +02:00
|
|
|
_nm_properties_override_gobj(
|
|
|
|
|
properties_override,
|
|
|
|
|
obj_properties[PROP_TIMESTAMP],
|
2021-06-18 09:44:46 +02:00
|
|
|
NM_SETT_INFO_PROPERT_TYPE_DBUS(G_VARIANT_TYPE_UINT64,
|
2021-06-30 00:05:49 +02:00
|
|
|
.compare_fcn = compare_fcn_timestamp,
|
|
|
|
|
.to_dbus_fcn = _to_dbus_fcn_timestamp,
|
|
|
|
|
.from_dbus_fcn = _nm_setting_property_from_dbus_fcn_gprop,
|
|
|
|
|
.from_dbus_is_full = TRUE));
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
/**
|
|
|
|
|
* NMSettingConnection:read-only:
|
|
|
|
|
*
|
2023-03-14 08:48:07 +01:00
|
|
|
* This property is deprecated and has no meaning.
|
|
|
|
|
*
|
|
|
|
|
* Deprecated: 1.44: This property is deprecated and has no meaning.
|
2014-07-24 08:53:33 -04:00
|
|
|
**/
|
2021-06-28 17:28:21 +02:00
|
|
|
_nm_setting_property_define_direct_boolean(properties_override,
|
|
|
|
|
obj_properties,
|
|
|
|
|
NM_SETTING_CONNECTION_READ_ONLY,
|
|
|
|
|
PROP_READ_ONLY,
|
|
|
|
|
FALSE,
|
|
|
|
|
NM_SETTING_PARAM_FUZZY_IGNORE,
|
|
|
|
|
NMSettingConnectionPrivate,
|
2023-03-14 08:48:07 +01:00
|
|
|
read_only,
|
|
|
|
|
.is_deprecated = TRUE, );
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
/**
|
|
|
|
|
* NMSettingConnection:zone:
|
|
|
|
|
*
|
|
|
|
|
* The trust level of a the connection. Free form case-insensitive string
|
|
|
|
|
* (for example "Home", "Work", "Public"). %NULL or unspecified zone means
|
|
|
|
|
* the connection will be placed in the default zone as defined by the
|
|
|
|
|
* firewall.
|
2015-09-18 17:21:34 +02:00
|
|
|
*
|
|
|
|
|
* When updating this property on a currently activated connection,
|
|
|
|
|
* the change takes effect immediately.
|
2014-07-24 08:53:33 -04:00
|
|
|
**/
|
libnm, libnm-util: move settings doc generation to libnm-core
Move the settings/plugins doc generation from libnm-util to
libnm-core, since libnm-util isn't being updated for all new
properties.
With this commit, the keyfile and ifcfg-rh documentation is basically
unchanged, except that deprecated properties are now gone, and new
properties have been added, and the sections are in a different order.
(generate-plugin-docs.pl just outputs the settings in Makefile order,
and they were unsorted in libnm-util, but are sorted in libnm-core).
The settings documentation used for nm-settings.5, the D-Bus API docs,
and the nmcli help is changed a bit more at this point, and mostly for
the worse, since the libnm-core setting properties don't match up with
the D-Bus API as well as the libnm-util ones do. To be fixed...
(I also removed the "plugins docs" line in each plugin docs comment
block while moving them, since those blocks will be used for more than
just plugins soon, and it's sort of obvious anyway.)
2014-10-28 09:58:25 -04:00
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: zone
|
|
|
|
|
* variable: ZONE(+)
|
|
|
|
|
* description: Trust level of this connection. The string is usually used
|
|
|
|
|
* for a firewall.
|
|
|
|
|
* example: ZONE=Work
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
2021-06-28 17:28:21 +02:00
|
|
|
_nm_setting_property_define_direct_string(properties_override,
|
|
|
|
|
obj_properties,
|
|
|
|
|
NM_SETTING_CONNECTION_ZONE,
|
|
|
|
|
PROP_ZONE,
|
|
|
|
|
NM_SETTING_PARAM_FUZZY_IGNORE
|
|
|
|
|
| NM_SETTING_PARAM_REAPPLY_IMMEDIATELY,
|
|
|
|
|
NMSettingConnectionPrivate,
|
|
|
|
|
zone);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
/**
|
|
|
|
|
* NMSettingConnection:master:
|
|
|
|
|
*
|
|
|
|
|
* Interface name of the master device or UUID of the master connection.
|
|
|
|
|
**/
|
libnm, libnm-util: move settings doc generation to libnm-core
Move the settings/plugins doc generation from libnm-util to
libnm-core, since libnm-util isn't being updated for all new
properties.
With this commit, the keyfile and ifcfg-rh documentation is basically
unchanged, except that deprecated properties are now gone, and new
properties have been added, and the sections are in a different order.
(generate-plugin-docs.pl just outputs the settings in Makefile order,
and they were unsorted in libnm-util, but are sorted in libnm-core).
The settings documentation used for nm-settings.5, the D-Bus API docs,
and the nmcli help is changed a bit more at this point, and mostly for
the worse, since the libnm-core setting properties don't match up with
the D-Bus API as well as the libnm-util ones do. To be fixed...
(I also removed the "plugins docs" line in each plugin docs comment
block while moving them, since those blocks will be used for more than
just plugins soon, and it's sort of obvious anyway.)
2014-10-28 09:58:25 -04:00
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: master
|
2016-11-28 12:32:03 +00:00
|
|
|
* variable: MASTER, MASTER_UUID, TEAM_MASTER, TEAM_MASTER_UUID, BRIDGE, BRIDGE_UUID
|
libnm, libnm-util: move settings doc generation to libnm-core
Move the settings/plugins doc generation from libnm-util to
libnm-core, since libnm-util isn't being updated for all new
properties.
With this commit, the keyfile and ifcfg-rh documentation is basically
unchanged, except that deprecated properties are now gone, and new
properties have been added, and the sections are in a different order.
(generate-plugin-docs.pl just outputs the settings in Makefile order,
and they were unsorted in libnm-util, but are sorted in libnm-core).
The settings documentation used for nm-settings.5, the D-Bus API docs,
and the nmcli help is changed a bit more at this point, and mostly for
the worse, since the libnm-core setting properties don't match up with
the D-Bus API as well as the libnm-util ones do. To be fixed...
(I also removed the "plugins docs" line in each plugin docs comment
block while moving them, since those blocks will be used for more than
just plugins soon, and it's sort of obvious anyway.)
2014-10-28 09:58:25 -04:00
|
|
|
* description: Reference to master connection. The variable used depends on
|
2016-11-28 12:32:03 +00:00
|
|
|
* the connection type and the value. In general, if the *_UUID variant is present,
|
|
|
|
|
* the variant without *_UUID is ignored. NetworkManager attempts to write both
|
|
|
|
|
* for compatibility with legacy tooling.
|
libnm, libnm-util: move settings doc generation to libnm-core
Move the settings/plugins doc generation from libnm-util to
libnm-core, since libnm-util isn't being updated for all new
properties.
With this commit, the keyfile and ifcfg-rh documentation is basically
unchanged, except that deprecated properties are now gone, and new
properties have been added, and the sections are in a different order.
(generate-plugin-docs.pl just outputs the settings in Makefile order,
and they were unsorted in libnm-util, but are sorted in libnm-core).
The settings documentation used for nm-settings.5, the D-Bus API docs,
and the nmcli help is changed a bit more at this point, and mostly for
the worse, since the libnm-core setting properties don't match up with
the D-Bus API as well as the libnm-util ones do. To be fixed...
(I also removed the "plugins docs" line in each plugin docs comment
block while moving them, since those blocks will be used for more than
just plugins soon, and it's sort of obvious anyway.)
2014-10-28 09:58:25 -04:00
|
|
|
* ---end---
|
|
|
|
|
*/
|
2021-06-28 17:28:21 +02:00
|
|
|
_nm_setting_property_define_direct_string(properties_override,
|
|
|
|
|
obj_properties,
|
|
|
|
|
NM_SETTING_CONNECTION_MASTER,
|
|
|
|
|
PROP_MASTER,
|
|
|
|
|
NM_SETTING_PARAM_FUZZY_IGNORE
|
|
|
|
|
| NM_SETTING_PARAM_INFERRABLE,
|
|
|
|
|
NMSettingConnectionPrivate,
|
|
|
|
|
master);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
/**
|
|
|
|
|
* NMSettingConnection:slave-type:
|
|
|
|
|
*
|
|
|
|
|
* Setting name of the device type of this slave's master connection (eg,
|
|
|
|
|
* %NM_SETTING_BOND_SETTING_NAME), or %NULL if this connection is not a
|
|
|
|
|
* slave.
|
|
|
|
|
**/
|
libnm, libnm-util: move settings doc generation to libnm-core
Move the settings/plugins doc generation from libnm-util to
libnm-core, since libnm-util isn't being updated for all new
properties.
With this commit, the keyfile and ifcfg-rh documentation is basically
unchanged, except that deprecated properties are now gone, and new
properties have been added, and the sections are in a different order.
(generate-plugin-docs.pl just outputs the settings in Makefile order,
and they were unsorted in libnm-util, but are sorted in libnm-core).
The settings documentation used for nm-settings.5, the D-Bus API docs,
and the nmcli help is changed a bit more at this point, and mostly for
the worse, since the libnm-core setting properties don't match up with
the D-Bus API as well as the libnm-util ones do. To be fixed...
(I also removed the "plugins docs" line in each plugin docs comment
block while moving them, since those blocks will be used for more than
just plugins soon, and it's sort of obvious anyway.)
2014-10-28 09:58:25 -04:00
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: slave-type
|
2016-11-28 12:32:03 +00:00
|
|
|
* variable: MASTER, MASTER_UUID, TEAM_MASTER, TEAM_MASTER_UUID, DEVICETYPE,
|
|
|
|
|
* BRIDGE, BRIDGE_UUID
|
libnm, libnm-util: move settings doc generation to libnm-core
Move the settings/plugins doc generation from libnm-util to
libnm-core, since libnm-util isn't being updated for all new
properties.
With this commit, the keyfile and ifcfg-rh documentation is basically
unchanged, except that deprecated properties are now gone, and new
properties have been added, and the sections are in a different order.
(generate-plugin-docs.pl just outputs the settings in Makefile order,
and they were unsorted in libnm-util, but are sorted in libnm-core).
The settings documentation used for nm-settings.5, the D-Bus API docs,
and the nmcli help is changed a bit more at this point, and mostly for
the worse, since the libnm-core setting properties don't match up with
the D-Bus API as well as the libnm-util ones do. To be fixed...
(I also removed the "plugins docs" line in each plugin docs comment
block while moving them, since those blocks will be used for more than
just plugins soon, and it's sort of obvious anyway.)
2014-10-28 09:58:25 -04:00
|
|
|
* description: Slave type doesn't map directly to a variable, but it is
|
2016-11-28 12:32:03 +00:00
|
|
|
* recognized using different variables. MASTER and MASTER_UUID for bonding,
|
|
|
|
|
* TEAM_MASTER, TEAM_MASTER_UUID and DEVICETYPE for teaming, BRIDGE
|
|
|
|
|
* and BRIDGE_UUID for bridging.
|
libnm, libnm-util: move settings doc generation to libnm-core
Move the settings/plugins doc generation from libnm-util to
libnm-core, since libnm-util isn't being updated for all new
properties.
With this commit, the keyfile and ifcfg-rh documentation is basically
unchanged, except that deprecated properties are now gone, and new
properties have been added, and the sections are in a different order.
(generate-plugin-docs.pl just outputs the settings in Makefile order,
and they were unsorted in libnm-util, but are sorted in libnm-core).
The settings documentation used for nm-settings.5, the D-Bus API docs,
and the nmcli help is changed a bit more at this point, and mostly for
the worse, since the libnm-core setting properties don't match up with
the D-Bus API as well as the libnm-util ones do. To be fixed...
(I also removed the "plugins docs" line in each plugin docs comment
block while moving them, since those blocks will be used for more than
just plugins soon, and it's sort of obvious anyway.)
2014-10-28 09:58:25 -04:00
|
|
|
* ---end---
|
|
|
|
|
*/
|
2021-06-28 17:28:21 +02:00
|
|
|
_nm_setting_property_define_direct_string(properties_override,
|
|
|
|
|
obj_properties,
|
|
|
|
|
NM_SETTING_CONNECTION_SLAVE_TYPE,
|
|
|
|
|
PROP_SLAVE_TYPE,
|
|
|
|
|
NM_SETTING_PARAM_FUZZY_IGNORE
|
|
|
|
|
| NM_SETTING_PARAM_INFERRABLE,
|
|
|
|
|
NMSettingConnectionPrivate,
|
|
|
|
|
slave_type);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2015-05-06 10:54:35 +02:00
|
|
|
/**
|
|
|
|
|
* NMSettingConnection:autoconnect-slaves:
|
|
|
|
|
*
|
|
|
|
|
* Whether or not slaves of this connection should be automatically brought up
|
|
|
|
|
* when NetworkManager activates this connection. This only has a real effect
|
2018-04-12 11:44:58 +02:00
|
|
|
* for master connections. The properties #NMSettingConnection:autoconnect,
|
|
|
|
|
* #NMSettingConnection:autoconnect-priority and #NMSettingConnection:autoconnect-retries
|
|
|
|
|
* are unrelated to this setting.
|
2015-05-06 10:54:35 +02:00
|
|
|
* The permitted values are: 0: leave slave connections untouched,
|
|
|
|
|
* 1: activate all the slave connections with this connection, -1: default.
|
|
|
|
|
* If -1 (default) is set, global connection.autoconnect-slaves is read to
|
|
|
|
|
* determine the real value. If it is default as well, this fallbacks to 0.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.2
|
|
|
|
|
**/
|
|
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: autoconnect-slaves
|
2017-09-19 08:34:48 +02:00
|
|
|
* variable: AUTOCONNECT_SLAVES(+)
|
2015-05-06 10:59:11 +02:00
|
|
|
* default: missing variable means global default
|
2015-05-06 10:54:35 +02:00
|
|
|
* description: Whether slaves of this connection should be auto-connected
|
|
|
|
|
* when this connection is activated.
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
2021-10-20 16:13:14 +02:00
|
|
|
_nm_setting_property_define_direct_enum(properties_override,
|
|
|
|
|
obj_properties,
|
|
|
|
|
NM_SETTING_CONNECTION_AUTOCONNECT_SLAVES,
|
|
|
|
|
PROP_AUTOCONNECT_SLAVES,
|
|
|
|
|
NM_TYPE_SETTING_CONNECTION_AUTOCONNECT_SLAVES,
|
|
|
|
|
NM_SETTING_CONNECTION_AUTOCONNECT_SLAVES_DEFAULT,
|
|
|
|
|
NM_SETTING_PARAM_FUZZY_IGNORE,
|
|
|
|
|
NMSettingConnectionPrivate,
|
|
|
|
|
autoconnect_slaves);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
/**
|
|
|
|
|
* NMSettingConnection:secondaries:
|
|
|
|
|
*
|
|
|
|
|
* List of connection UUIDs that should be activated when the base
|
2020-07-01 17:20:40 -04:00
|
|
|
* connection itself is activated. Currently, only VPN connections are
|
2014-07-24 08:53:33 -04:00
|
|
|
* supported.
|
|
|
|
|
**/
|
libnm, libnm-util: move settings doc generation to libnm-core
Move the settings/plugins doc generation from libnm-util to
libnm-core, since libnm-util isn't being updated for all new
properties.
With this commit, the keyfile and ifcfg-rh documentation is basically
unchanged, except that deprecated properties are now gone, and new
properties have been added, and the sections are in a different order.
(generate-plugin-docs.pl just outputs the settings in Makefile order,
and they were unsorted in libnm-util, but are sorted in libnm-core).
The settings documentation used for nm-settings.5, the D-Bus API docs,
and the nmcli help is changed a bit more at this point, and mostly for
the worse, since the libnm-core setting properties don't match up with
the D-Bus API as well as the libnm-util ones do. To be fixed...
(I also removed the "plugins docs" line in each plugin docs comment
block while moving them, since those blocks will be used for more than
just plugins soon, and it's sort of obvious anyway.)
2014-10-28 09:58:25 -04:00
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: secondaries
|
|
|
|
|
* variable: SECONDARY_UUIDS(+)
|
|
|
|
|
* description: UUID of VPN connections that should be activated
|
|
|
|
|
* together with this connection.
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
2022-01-24 17:24:25 +01:00
|
|
|
_nm_setting_property_define_direct_strv(properties_override,
|
|
|
|
|
obj_properties,
|
|
|
|
|
NM_SETTING_CONNECTION_SECONDARIES,
|
|
|
|
|
PROP_SECONDARIES,
|
|
|
|
|
NM_SETTING_PARAM_FUZZY_IGNORE,
|
|
|
|
|
NMSettingConnectionPrivate,
|
|
|
|
|
secondaries);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2014-07-24 08:53:33 -04:00
|
|
|
/**
|
|
|
|
|
* NMSettingConnection:gateway-ping-timeout:
|
|
|
|
|
*
|
|
|
|
|
* If greater than zero, delay success of IP addressing until either the
|
|
|
|
|
* timeout is reached, or an IP gateway replies to a ping.
|
|
|
|
|
**/
|
libnm, libnm-util: move settings doc generation to libnm-core
Move the settings/plugins doc generation from libnm-util to
libnm-core, since libnm-util isn't being updated for all new
properties.
With this commit, the keyfile and ifcfg-rh documentation is basically
unchanged, except that deprecated properties are now gone, and new
properties have been added, and the sections are in a different order.
(generate-plugin-docs.pl just outputs the settings in Makefile order,
and they were unsorted in libnm-util, but are sorted in libnm-core).
The settings documentation used for nm-settings.5, the D-Bus API docs,
and the nmcli help is changed a bit more at this point, and mostly for
the worse, since the libnm-core setting properties don't match up with
the D-Bus API as well as the libnm-util ones do. To be fixed...
(I also removed the "plugins docs" line in each plugin docs comment
block while moving them, since those blocks will be used for more than
just plugins soon, and it's sort of obvious anyway.)
2014-10-28 09:58:25 -04:00
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: gateway-ping-timeout
|
|
|
|
|
* variable: GATEWAY_PING_TIMEOUT(+)
|
|
|
|
|
* default: 0
|
|
|
|
|
* description: If greater than zero, the IP connectivity will be checked by
|
|
|
|
|
* pinging the gateway and waiting for the specified timeout (in seconds).
|
|
|
|
|
* example: GATEWAY_PING_TIMEOUT=5
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
2021-07-13 17:37:08 +02:00
|
|
|
_nm_setting_property_define_direct_uint32(properties_override,
|
|
|
|
|
obj_properties,
|
|
|
|
|
NM_SETTING_CONNECTION_GATEWAY_PING_TIMEOUT,
|
|
|
|
|
PROP_GATEWAY_PING_TIMEOUT,
|
|
|
|
|
0,
|
|
|
|
|
600,
|
|
|
|
|
0,
|
|
|
|
|
NM_SETTING_PARAM_NONE,
|
|
|
|
|
NMSettingConnectionPrivate,
|
|
|
|
|
gateway_ping_timeout);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2015-04-27 17:45:53 +02:00
|
|
|
/**
|
|
|
|
|
* NMSettingConnection:metered:
|
|
|
|
|
*
|
|
|
|
|
* Whether the connection is metered.
|
|
|
|
|
*
|
2015-09-18 17:21:34 +02:00
|
|
|
* When updating this property on a currently activated connection,
|
|
|
|
|
* the change takes effect immediately.
|
|
|
|
|
*
|
2015-04-27 17:45:53 +02:00
|
|
|
* Since: 1.2
|
|
|
|
|
**/
|
2015-05-29 17:41:21 +02:00
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: metered
|
2016-12-09 22:19:48 +01:00
|
|
|
* variable: CONNECTION_METERED(+)
|
2015-05-29 17:41:21 +02:00
|
|
|
* values: yes,no,unknown
|
|
|
|
|
* description: Whether the device is metered
|
|
|
|
|
* example: CONNECTION_METERED=yes
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
2021-10-20 16:13:14 +02:00
|
|
|
_nm_setting_property_define_direct_enum(properties_override,
|
|
|
|
|
obj_properties,
|
|
|
|
|
NM_SETTING_CONNECTION_METERED,
|
|
|
|
|
PROP_METERED,
|
|
|
|
|
NM_TYPE_METERED,
|
|
|
|
|
NM_METERED_UNKNOWN,
|
|
|
|
|
NM_SETTING_PARAM_REAPPLY_IMMEDIATELY,
|
|
|
|
|
NMSettingConnectionPrivate,
|
|
|
|
|
metered);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2015-10-07 11:48:30 +02:00
|
|
|
/**
|
|
|
|
|
* NMSettingConnection:lldp:
|
|
|
|
|
*
|
|
|
|
|
* Whether LLDP is enabled for the connection.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.2
|
|
|
|
|
**/
|
2015-10-08 18:26:45 +02:00
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: lldp
|
2016-12-09 22:19:48 +01:00
|
|
|
* variable: LLDP(+)
|
2015-10-08 18:26:45 +02:00
|
|
|
* values: boolean value or 'rx'
|
|
|
|
|
* default: missing variable means global default
|
|
|
|
|
* description: whether LLDP is enabled for the connection
|
|
|
|
|
* example: LLDP=no
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
2021-07-13 17:37:08 +02:00
|
|
|
_nm_setting_property_define_direct_int32(properties_override,
|
|
|
|
|
obj_properties,
|
|
|
|
|
NM_SETTING_CONNECTION_LLDP,
|
|
|
|
|
PROP_LLDP,
|
|
|
|
|
G_MININT32,
|
|
|
|
|
G_MAXINT32,
|
|
|
|
|
NM_SETTING_CONNECTION_LLDP_DEFAULT,
|
|
|
|
|
NM_SETTING_PARAM_FUZZY_IGNORE,
|
|
|
|
|
NMSettingConnectionPrivate,
|
|
|
|
|
lldp);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2017-11-02 09:25:40 +01:00
|
|
|
/**
|
|
|
|
|
* NMSettingConnection:auth-retries:
|
|
|
|
|
*
|
|
|
|
|
* The number of retries for the authentication. Zero means to try indefinitely; -1 means
|
|
|
|
|
* to use a global default. If the global default is not set, the authentication
|
|
|
|
|
* retries for 3 times before failing the connection.
|
|
|
|
|
*
|
2020-07-01 17:20:40 -04:00
|
|
|
* Currently, this only applies to 802-1x authentication.
|
2017-11-02 09:25:40 +01:00
|
|
|
*
|
|
|
|
|
* Since: 1.10
|
|
|
|
|
**/
|
|
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: auth-retries
|
|
|
|
|
* variable: AUTH_RETRIES(+)
|
|
|
|
|
* default: 0
|
|
|
|
|
* description: Number of retries for authentication.
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
2021-07-13 17:37:08 +02:00
|
|
|
_nm_setting_property_define_direct_int32(properties_override,
|
|
|
|
|
obj_properties,
|
|
|
|
|
NM_SETTING_CONNECTION_AUTH_RETRIES,
|
|
|
|
|
PROP_AUTH_RETRIES,
|
|
|
|
|
-1,
|
|
|
|
|
G_MAXINT32,
|
|
|
|
|
-1,
|
|
|
|
|
NM_SETTING_PARAM_FUZZY_IGNORE,
|
|
|
|
|
NMSettingConnectionPrivate,
|
|
|
|
|
auth_retries);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2017-11-10 14:49:27 +02:00
|
|
|
/**
|
|
|
|
|
* NMSettingConnection:mdns:
|
|
|
|
|
*
|
|
|
|
|
* Whether mDNS is enabled for the connection.
|
|
|
|
|
*
|
2019-12-10 16:39:44 +01:00
|
|
|
* The permitted values are: "yes" (2) register hostname and resolving
|
|
|
|
|
* for the connection, "no" (0) disable mDNS for the interface, "resolve"
|
|
|
|
|
* (1) do not register hostname but allow resolving of mDNS host names
|
|
|
|
|
* and "default" (-1) to allow lookup of a global default in NetworkManager.conf.
|
|
|
|
|
* If unspecified, "default" ultimately depends on the DNS plugin (which
|
|
|
|
|
* for systemd-resolved currently means "no").
|
2017-11-10 14:49:27 +02:00
|
|
|
*
|
2020-07-01 17:20:40 -04:00
|
|
|
* This feature requires a plugin which supports mDNS. Otherwise, the
|
2019-12-10 16:39:44 +01:00
|
|
|
* setting has no effect. One such plugin is dns-systemd-resolved.
|
2021-07-13 17:37:08 +02:00
|
|
|
*
|
2017-11-10 14:49:27 +02:00
|
|
|
* Since: 1.12
|
|
|
|
|
**/
|
|
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: mdns
|
2018-08-31 15:18:48 +02:00
|
|
|
* variable: MDNS(+)
|
2017-11-10 14:49:27 +02:00
|
|
|
* values: yes,no,resolve
|
|
|
|
|
* default: missing variable means global default
|
|
|
|
|
* description: Whether or not mDNS is enabled for the connection
|
2018-08-31 15:18:48 +02:00
|
|
|
* example: MDNS=yes
|
2017-11-10 14:49:27 +02:00
|
|
|
* ---end---
|
|
|
|
|
*/
|
2021-07-13 17:37:08 +02:00
|
|
|
_nm_setting_property_define_direct_int32(properties_override,
|
|
|
|
|
obj_properties,
|
|
|
|
|
NM_SETTING_CONNECTION_MDNS,
|
|
|
|
|
PROP_MDNS,
|
|
|
|
|
G_MININT32,
|
|
|
|
|
G_MAXINT32,
|
|
|
|
|
NM_SETTING_CONNECTION_MDNS_DEFAULT,
|
|
|
|
|
NM_SETTING_PARAM_NONE,
|
|
|
|
|
NMSettingConnectionPrivate,
|
|
|
|
|
mdns);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2018-08-31 10:48:18 +02:00
|
|
|
/**
|
|
|
|
|
* NMSettingConnection:llmnr:
|
|
|
|
|
*
|
|
|
|
|
* Whether Link-Local Multicast Name Resolution (LLMNR) is enabled
|
|
|
|
|
* for the connection. LLMNR is a protocol based on the Domain Name
|
|
|
|
|
* System (DNS) packet format that allows both IPv4 and IPv6 hosts
|
|
|
|
|
* to perform name resolution for hosts on the same local link.
|
|
|
|
|
*
|
2019-12-10 16:39:44 +01:00
|
|
|
* The permitted values are: "yes" (2) register hostname and resolving
|
|
|
|
|
* for the connection, "no" (0) disable LLMNR for the interface, "resolve"
|
|
|
|
|
* (1) do not register hostname but allow resolving of LLMNR host names
|
|
|
|
|
* If unspecified, "default" ultimately depends on the DNS plugin (which
|
|
|
|
|
* for systemd-resolved currently means "yes").
|
2018-08-31 10:48:18 +02:00
|
|
|
*
|
2020-07-01 17:20:40 -04:00
|
|
|
* This feature requires a plugin which supports LLMNR. Otherwise, the
|
2019-12-10 16:39:44 +01:00
|
|
|
* setting has no effect. One such plugin is dns-systemd-resolved.
|
2018-08-31 10:48:18 +02:00
|
|
|
*
|
|
|
|
|
* Since: 1.14
|
|
|
|
|
**/
|
2018-08-31 15:18:20 +02:00
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: llmnr
|
|
|
|
|
* variable: LLMNR(+)
|
|
|
|
|
* values: yes,no,resolve
|
|
|
|
|
* default: missing variable means global default
|
|
|
|
|
* description: Whether or not LLMNR is enabled for the connection
|
|
|
|
|
* example: LLMNR=yes
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
2021-07-13 17:37:08 +02:00
|
|
|
_nm_setting_property_define_direct_int32(properties_override,
|
|
|
|
|
obj_properties,
|
|
|
|
|
NM_SETTING_CONNECTION_LLMNR,
|
|
|
|
|
PROP_LLMNR,
|
|
|
|
|
G_MININT32,
|
|
|
|
|
G_MAXINT32,
|
|
|
|
|
NM_SETTING_CONNECTION_LLMNR_DEFAULT,
|
|
|
|
|
NM_SETTING_PARAM_NONE,
|
|
|
|
|
NMSettingConnectionPrivate,
|
|
|
|
|
llmnr);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2021-10-03 19:16:01 +02:00
|
|
|
/**
|
|
|
|
|
* NMSettingConnection:dns-over-tls:
|
|
|
|
|
*
|
|
|
|
|
* Whether DNSOverTls (dns-over-tls) is enabled for the connection.
|
|
|
|
|
* DNSOverTls is a technology which uses TLS to encrypt dns traffic.
|
|
|
|
|
*
|
|
|
|
|
* The permitted values are: "yes" (2) use DNSOverTls and disabled fallback,
|
|
|
|
|
* "opportunistic" (1) use DNSOverTls but allow fallback to unencrypted resolution,
|
|
|
|
|
* "no" (0) don't ever use DNSOverTls.
|
|
|
|
|
* If unspecified "default" depends on the plugin used. Systemd-resolved
|
|
|
|
|
* uses global setting.
|
|
|
|
|
*
|
|
|
|
|
* This feature requires a plugin which supports DNSOverTls. Otherwise, the
|
|
|
|
|
* setting has no effect. One such plugin is dns-systemd-resolved.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.34
|
|
|
|
|
**/
|
2021-10-03 14:14:36 +02:00
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: dns-over-tls
|
|
|
|
|
* variable: DNS_OVER_TLS(+)
|
|
|
|
|
* values: yes,no,opportunistic
|
|
|
|
|
* default: missing variable means global default
|
|
|
|
|
* description: Whether or not DNSOverTls is enabled for the connection
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
2021-10-03 19:16:01 +02:00
|
|
|
_nm_setting_property_define_direct_int32(properties_override,
|
|
|
|
|
obj_properties,
|
|
|
|
|
NM_SETTING_CONNECTION_DNS_OVER_TLS,
|
|
|
|
|
PROP_DNS_OVER_TLS,
|
|
|
|
|
G_MININT32,
|
|
|
|
|
G_MAXINT32,
|
|
|
|
|
NM_SETTING_CONNECTION_DNS_OVER_TLS_DEFAULT,
|
|
|
|
|
NM_SETTING_PARAM_NONE,
|
|
|
|
|
NMSettingConnectionPrivate,
|
|
|
|
|
dns_over_tls);
|
|
|
|
|
|
2022-07-18 21:24:09 +02:00
|
|
|
/* Notes about "mptcp-flags":
|
|
|
|
|
*
|
|
|
|
|
* It is a bit odd that NMMptcpFlags mixes flags with different purposes:
|
|
|
|
|
*
|
|
|
|
|
* - "disabled", "disabled-on-local-iface", "enable": whether MPTCP handling
|
|
|
|
|
* is enabled. The flag "disabled-on-local-iface" enables it based on whether
|
|
|
|
|
* the interface has a default route.
|
|
|
|
|
* - "signal", "subflow", "backup", "fullmesh": the endpoint flags
|
|
|
|
|
* that are used.
|
|
|
|
|
*
|
|
|
|
|
* The reason is, that it is useful to have one "connection.mptcp-flags"
|
|
|
|
|
* property, that can express various aspects at once. The alternatives
|
|
|
|
|
* would be multiple properties like "connection.mptcp-enabled",
|
|
|
|
|
* "connection.mptcp-addr-flags" and "connection.mptcp-notify-flags".
|
|
|
|
|
* More properties does not necessarily make the API simpler. In particular
|
|
|
|
|
* for something like MPTCP, which should just work by default and only
|
|
|
|
|
* in special cases require special configuration.
|
|
|
|
|
*
|
|
|
|
|
* The entire idea is to only have one "connection.mptcp-flags" property (for now).
|
|
|
|
|
* That one can encode multiple aspects about MPTCP, whether it's enabled at all,
|
|
|
|
|
* which address flags to use when configuring endpoints, and opt-in addresses
|
|
|
|
|
* that otherwise would not be configured as endpoints.
|
|
|
|
|
*
|
|
|
|
|
* "connection.mptcp-flags" applies to all addresses on the interface (minus the ones
|
2022-08-05 15:30:38 +02:00
|
|
|
* that are not included by default). The idea is that in the future we could have
|
2022-07-18 21:24:09 +02:00
|
|
|
* more properties like "ipv4.dhcp-mptcp-flags=subflow", "ipv6.link-local-mptcp-flags=disabled",
|
|
|
|
|
* "ipv4.addresses='192.168.1.5/24 mptcp-flags=signal,backup'", which can overwrite the
|
|
|
|
|
* flags on a per-address basis.
|
|
|
|
|
*
|
|
|
|
|
* But for that future extension, we now need a global "connection.mptcp-flags" property
|
|
|
|
|
* in the API that is the basis and applies to all addresses.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* NMSettingConnection:mptcp-flags:
|
|
|
|
|
*
|
|
|
|
|
* Whether to configure MPTCP endpoints and the address flags.
|
|
|
|
|
* If MPTCP is enabled in NetworkManager, it will configure the
|
2022-08-05 15:30:38 +02:00
|
|
|
* addresses of the interface as MPTCP endpoints. Note that
|
|
|
|
|
* IPv4 loopback addresses (127.0.0.0/8), IPv4 link local
|
|
|
|
|
* addresses (169.254.0.0/16), the IPv6 loopback address (::1),
|
|
|
|
|
* IPv6 link local addresses (fe80::/10), IPv6 unique
|
|
|
|
|
* local addresses (ULA, fc00::/7) and IPv6 privacy extension addresses
|
|
|
|
|
* (rfc3041, ipv6.ip6-privacy) will be excluded from being
|
|
|
|
|
* configured as endpoints.
|
2022-07-18 21:24:09 +02:00
|
|
|
*
|
|
|
|
|
* If "disabled" (0x1), MPTCP handling for the interface is disabled and
|
|
|
|
|
* no endpoints are registered.
|
|
|
|
|
*
|
mptcp: rework "connection.mptcp-flags" for enabling MPTCP
1) The "enabled-on-global-iface" flag was odd. Instead, have only
and "enabled" flag and skip (by default) endpoints on interface
that have no default route. With the new flag "also-without-default-route",
this can be overruled. So previous "enabled-on-global-default" now is
the same as "enabled", and "enabled" from before behaves now like
"enabled,also-without-default-route".
2) What was also odd, as that the fallback default value for the flags
depends on "/proc/sys/net/mptcp/enabled". There was not one fixed
fallback default, instead the used fallback value was either
"enabled-on-global-iface,subflow" or "disabled".
Usually that is not a problem (e.g. the default value for
"ipv6.ip6-privacy" also depends on use_tempaddr sysctl). In this case
it is a problem, because the mptcp-flags (for better or worse) encode
different things at the same time.
Consider that the mptcp-flags can also have their default configured in
"NetworkManager.conf", a user who wants to switch the address flags
could previously do:
[connection.mptcp]
connection.mptcp-flags=0x32 # enabled-on-global-iface,signal,subflow
but then the global toggle "/proc/sys/net/mptcp/enabled" was no longer
honored. That means, MPTCP handling was always on, even if the sysctl was
disabled. Now, "enabled" means that it's only enabled if the sysctl
is enabled too. Now the user could write to "NetworkManager.conf"
[connection.mptcp]
connection.mptcp-flags=0x32 # enabled,signal,subflow
and MPTCP handling would still be disabled unless the sysctl
is enabled.
There is now also a new flag "also-without-sysctl", so if you want
to really enable MPTCP handling regardless of the sysctl, you can.
The point of that might be, that we still can configure endpoints,
even if kernel won't do anything with them. Then you could just flip
the sysctl, and it would start working (as NetworkManager configured
the endpoints already).
Fixes: eb083eece5a2 ('all: add NMMptcpFlags and connection.mptcp-flags property')
(cherry picked from commit c00873e08f4d0bc4a3f0b8a93beb793fcab78afa)
2022-08-25 09:40:46 +02:00
|
|
|
* The "enabled" (0x2) flag means that MPTCP handling is enabled.
|
2022-07-18 21:24:09 +02:00
|
|
|
* This flag can also be implied from the presence of other flags.
|
|
|
|
|
*
|
mptcp: rework "connection.mptcp-flags" for enabling MPTCP
1) The "enabled-on-global-iface" flag was odd. Instead, have only
and "enabled" flag and skip (by default) endpoints on interface
that have no default route. With the new flag "also-without-default-route",
this can be overruled. So previous "enabled-on-global-default" now is
the same as "enabled", and "enabled" from before behaves now like
"enabled,also-without-default-route".
2) What was also odd, as that the fallback default value for the flags
depends on "/proc/sys/net/mptcp/enabled". There was not one fixed
fallback default, instead the used fallback value was either
"enabled-on-global-iface,subflow" or "disabled".
Usually that is not a problem (e.g. the default value for
"ipv6.ip6-privacy" also depends on use_tempaddr sysctl). In this case
it is a problem, because the mptcp-flags (for better or worse) encode
different things at the same time.
Consider that the mptcp-flags can also have their default configured in
"NetworkManager.conf", a user who wants to switch the address flags
could previously do:
[connection.mptcp]
connection.mptcp-flags=0x32 # enabled-on-global-iface,signal,subflow
but then the global toggle "/proc/sys/net/mptcp/enabled" was no longer
honored. That means, MPTCP handling was always on, even if the sysctl was
disabled. Now, "enabled" means that it's only enabled if the sysctl
is enabled too. Now the user could write to "NetworkManager.conf"
[connection.mptcp]
connection.mptcp-flags=0x32 # enabled,signal,subflow
and MPTCP handling would still be disabled unless the sysctl
is enabled.
There is now also a new flag "also-without-sysctl", so if you want
to really enable MPTCP handling regardless of the sysctl, you can.
The point of that might be, that we still can configure endpoints,
even if kernel won't do anything with them. Then you could just flip
the sysctl, and it would start working (as NetworkManager configured
the endpoints already).
Fixes: eb083eece5a2 ('all: add NMMptcpFlags and connection.mptcp-flags property')
(cherry picked from commit c00873e08f4d0bc4a3f0b8a93beb793fcab78afa)
2022-08-25 09:40:46 +02:00
|
|
|
* Even when enabled, MPTCP handling will by default still be disabled
|
|
|
|
|
* unless "/proc/sys/net/mptcp/enabled" sysctl is on. NetworkManager
|
|
|
|
|
* does not change the sysctl and this is up to the administrator
|
|
|
|
|
* or distribution. To configure endpoints even if the sysctl is
|
|
|
|
|
* disabled, "also-without-sysctl" (0x4) flag can be used. In that case,
|
|
|
|
|
* NetworkManager doesn't look at the sysctl and configures endpoints
|
|
|
|
|
* regardless.
|
|
|
|
|
*
|
|
|
|
|
* Even when enabled, NetworkManager will only configure MPTCP endpoints
|
|
|
|
|
* for a certain address family, if there is a unicast default route (0.0.0.0/0
|
|
|
|
|
* or ::/0) in the main routing table. The flag "also-without-default-route"
|
|
|
|
|
* (0x8) can override that.
|
|
|
|
|
*
|
|
|
|
|
* When MPTCP handling is enabled then endpoints are configured with
|
|
|
|
|
* the specified address flags "signal" (0x10), "subflow" (0x20), "backup" (0x40),
|
2022-07-18 21:24:09 +02:00
|
|
|
* "fullmesh" (0x80). See ip-mptcp(8) manual for additional information about the flags.
|
|
|
|
|
*
|
mptcp: rework "connection.mptcp-flags" for enabling MPTCP
1) The "enabled-on-global-iface" flag was odd. Instead, have only
and "enabled" flag and skip (by default) endpoints on interface
that have no default route. With the new flag "also-without-default-route",
this can be overruled. So previous "enabled-on-global-default" now is
the same as "enabled", and "enabled" from before behaves now like
"enabled,also-without-default-route".
2) What was also odd, as that the fallback default value for the flags
depends on "/proc/sys/net/mptcp/enabled". There was not one fixed
fallback default, instead the used fallback value was either
"enabled-on-global-iface,subflow" or "disabled".
Usually that is not a problem (e.g. the default value for
"ipv6.ip6-privacy" also depends on use_tempaddr sysctl). In this case
it is a problem, because the mptcp-flags (for better or worse) encode
different things at the same time.
Consider that the mptcp-flags can also have their default configured in
"NetworkManager.conf", a user who wants to switch the address flags
could previously do:
[connection.mptcp]
connection.mptcp-flags=0x32 # enabled-on-global-iface,signal,subflow
but then the global toggle "/proc/sys/net/mptcp/enabled" was no longer
honored. That means, MPTCP handling was always on, even if the sysctl was
disabled. Now, "enabled" means that it's only enabled if the sysctl
is enabled too. Now the user could write to "NetworkManager.conf"
[connection.mptcp]
connection.mptcp-flags=0x32 # enabled,signal,subflow
and MPTCP handling would still be disabled unless the sysctl
is enabled.
There is now also a new flag "also-without-sysctl", so if you want
to really enable MPTCP handling regardless of the sysctl, you can.
The point of that might be, that we still can configure endpoints,
even if kernel won't do anything with them. Then you could just flip
the sysctl, and it would start working (as NetworkManager configured
the endpoints already).
Fixes: eb083eece5a2 ('all: add NMMptcpFlags and connection.mptcp-flags property')
(cherry picked from commit c00873e08f4d0bc4a3f0b8a93beb793fcab78afa)
2022-08-25 09:40:46 +02:00
|
|
|
* If the flags are zero (0x0), the global connection default from NetworkManager.conf is
|
|
|
|
|
* honored. If still unspecified, the fallback is "enabled,subflow".
|
|
|
|
|
* Note that this means that MPTCP is by default done depending on the
|
|
|
|
|
* "/proc/sys/net/mptcp/enabled" sysctl.
|
2022-07-18 21:24:09 +02:00
|
|
|
*
|
|
|
|
|
* NetworkManager does not change the MPTCP limits nor enable MPTCP via
|
|
|
|
|
* "/proc/sys/net/mptcp/enabled". That is a host configuration which the
|
|
|
|
|
* admin can change via sysctl and ip-mptcp.
|
|
|
|
|
*
|
2022-08-05 15:30:38 +02:00
|
|
|
* Strict reverse path filtering (rp_filter) breaks many MPTCP use cases, so when
|
|
|
|
|
* MPTCP handling for IPv4 addresses on the interface is enabled, NetworkManager would
|
|
|
|
|
* loosen the strict reverse path filtering (1) to the loose setting (2).
|
|
|
|
|
*
|
2022-07-18 21:24:09 +02:00
|
|
|
* Since: 1.40
|
|
|
|
|
**/
|
|
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: mptcp-flags
|
|
|
|
|
* variable: MPTCP_FLAGS(+)
|
|
|
|
|
* default: missing variable means global default
|
|
|
|
|
* description: The MPTCP flags that indicate whether MPTCP is enabled
|
|
|
|
|
* and which flags to use for the address endpoints.
|
|
|
|
|
* example: MPTCP_FLAGS="signal,subflow"
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
|
|
|
|
_nm_setting_property_define_direct_uint32(properties_override,
|
|
|
|
|
obj_properties,
|
|
|
|
|
NM_SETTING_CONNECTION_MPTCP_FLAGS,
|
|
|
|
|
PROP_MPTCP_FLAGS,
|
|
|
|
|
0,
|
|
|
|
|
G_MAXUINT32,
|
|
|
|
|
NM_MPTCP_FLAGS_NONE,
|
|
|
|
|
NM_SETTING_PARAM_NONE,
|
|
|
|
|
NMSettingConnectionPrivate,
|
|
|
|
|
mptcp_flags);
|
|
|
|
|
|
2019-07-01 10:01:28 +02:00
|
|
|
/**
|
|
|
|
|
* NMSettingConnection:wait-device-timeout:
|
|
|
|
|
*
|
|
|
|
|
* Timeout in milliseconds to wait for device at startup.
|
|
|
|
|
* During boot, devices may take a while to be detected by the driver.
|
|
|
|
|
* This property will cause to delay NetworkManager-wait-online.service
|
settings: rework wait-device-timeout handling and consider device compatibility
A profile can configure "connection.wait-device-timeout" to indicate
that startup complete is blocked until a suitable device around.
This is useful for NetworkManager-wait-online and initrd mode.
Previously, we looked at NMPlatform whether a link with matching
interface-name was present. That is wrong because it cannot handle
profiles that rely on "ethernet.mac-address" setting or other "match"
settings. Also, the mere presence of the link does not yet mean
that the NMDevice was created and ready. In fact, there is a race here:
NMPlatform indicates that the device is ready (unblocking NMSettings),
but there is no corresponding NMDevice yet which keeps NetworkManager
busy to block startup complete.
Rework this. Now, only check whether there is a compatible device for
the profile.
Since we wait for compatible devices, it works now not only for the
interface name. Note that we do some optimizations so that we don't have
to re-evaluate all profiles (w.r.t. all devices) whenever something on the
device changes: we only care about this when all devices finally become
ready.
Also, we no longer start the timeout for "connection.wait-device-timeout"
when the profile appears. Instead, there is one system-wide start time
(NMSettingsPrivate.startup_complete_start_timestamp_msec). That simplifies
code and makes sense: we start waiting when NetworkManager is starting, not
when the profile gets added. Also, we wait for all profiles to become
ready together.
2020-08-11 15:34:59 +02:00
|
|
|
* and nm-online to give the device a chance to appear. This works by
|
|
|
|
|
* waiting for the given timeout until a compatible device for the
|
|
|
|
|
* profile is available and managed.
|
2019-07-01 10:01:28 +02:00
|
|
|
*
|
|
|
|
|
* The value 0 means no wait time. The default value is -1, which
|
|
|
|
|
* currently has the same meaning as no wait time.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.20
|
|
|
|
|
**/
|
|
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: wait-device-timeout
|
|
|
|
|
* variable: DEVTIMEOUT(+)
|
|
|
|
|
* values: timeout in seconds.
|
|
|
|
|
* description: for initscripts compatibility, this variable must be
|
|
|
|
|
* a whole integer. If necessary, NetworkManager stores also a fractional
|
|
|
|
|
* component for the milliseconds.
|
|
|
|
|
* example: DEVTIMEOUT=5
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
2021-07-13 17:37:08 +02:00
|
|
|
_nm_setting_property_define_direct_int32(properties_override,
|
|
|
|
|
obj_properties,
|
|
|
|
|
NM_SETTING_CONNECTION_WAIT_DEVICE_TIMEOUT,
|
|
|
|
|
PROP_WAIT_DEVICE_TIMEOUT,
|
|
|
|
|
-1,
|
|
|
|
|
G_MAXINT32,
|
|
|
|
|
-1,
|
|
|
|
|
NM_SETTING_PARAM_NONE,
|
|
|
|
|
NMSettingConnectionPrivate,
|
|
|
|
|
wait_device_timeout);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2020-04-08 07:30:08 +00:00
|
|
|
/**
|
|
|
|
|
* NMSettingConnection:mud-url:
|
|
|
|
|
*
|
|
|
|
|
* If configured, set to a Manufacturer Usage Description (MUD) URL that points
|
|
|
|
|
* to manufacturer-recommended network policies for IoT devices. It is transmitted
|
2020-04-25 07:46:56 +02:00
|
|
|
* as a DHCPv4 or DHCPv6 option. The value must be a valid URL starting with "https://".
|
|
|
|
|
*
|
|
|
|
|
* The special value "none" is allowed to indicate that no MUD URL is used.
|
|
|
|
|
*
|
|
|
|
|
* If the per-profile value is unspecified (the default), a global connection default gets
|
|
|
|
|
* consulted. If still unspecified, the ultimate default is "none".
|
2020-04-08 07:30:08 +00:00
|
|
|
*
|
2020-04-24 09:20:25 +02:00
|
|
|
* Since: 1.26
|
2020-04-08 07:30:08 +00:00
|
|
|
**/
|
|
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: mud-url
|
|
|
|
|
* variable: MUD_URL
|
|
|
|
|
* values: a valid URL that points to recommended policy for this device
|
|
|
|
|
* description: MUD_URL to be sent by device (See RFC 8520).
|
|
|
|
|
* example: https://yourdevice.example.com/model.json
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
2021-06-28 17:28:21 +02:00
|
|
|
_nm_setting_property_define_direct_string(properties_override,
|
|
|
|
|
obj_properties,
|
|
|
|
|
NM_SETTING_CONNECTION_MUD_URL,
|
|
|
|
|
PROP_MUD_URL,
|
|
|
|
|
NM_SETTING_PARAM_NONE,
|
|
|
|
|
NMSettingConnectionPrivate,
|
|
|
|
|
mud_url);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2022-05-27 12:36:29 +02:00
|
|
|
/**
|
|
|
|
|
* NMSettingConnection:wait-activation-delay:
|
|
|
|
|
*
|
|
|
|
|
* Time in milliseconds to wait for connection to be considered activated.
|
|
|
|
|
* The wait will start after the pre-up dispatcher event.
|
|
|
|
|
*
|
|
|
|
|
* The value 0 means no wait time. The default value is -1, which
|
|
|
|
|
* currently has the same meaning as no wait time.
|
|
|
|
|
*
|
|
|
|
|
* Since: 1.40
|
|
|
|
|
**/
|
|
|
|
|
/* ---ifcfg-rh---
|
|
|
|
|
* property: wait-activation-delay
|
|
|
|
|
* variable: WAIT_ACTIVATION_DELAY(+)
|
|
|
|
|
* values: delay in milliseconds.
|
|
|
|
|
* description: Time in milliseconds to wait for connection to be considered activated.
|
|
|
|
|
* The wait will start after the pre-up dispatcher event.
|
|
|
|
|
* example: WAIT_ACTIVATION_DELAY=5000
|
|
|
|
|
* ---end---
|
|
|
|
|
*/
|
|
|
|
|
_nm_setting_property_define_direct_int32(properties_override,
|
|
|
|
|
obj_properties,
|
|
|
|
|
NM_SETTING_CONNECTION_WAIT_ACTIVATION_DELAY,
|
|
|
|
|
PROP_WAIT_ACTIVATION_DELAY,
|
|
|
|
|
-1,
|
|
|
|
|
G_MAXINT32,
|
|
|
|
|
-1,
|
|
|
|
|
NM_SETTING_PARAM_NONE,
|
|
|
|
|
NMSettingConnectionPrivate,
|
|
|
|
|
wait_activation_delay);
|
|
|
|
|
|
2019-01-11 08:28:26 +01:00
|
|
|
g_object_class_install_properties(object_class, _PROPERTY_ENUMS_LAST, obj_properties);
|
2020-09-28 16:03:33 +02:00
|
|
|
|
2021-06-28 14:53:16 +02:00
|
|
|
_nm_setting_class_commit(setting_class,
|
|
|
|
|
NM_META_SETTING_TYPE_CONNECTION,
|
|
|
|
|
NULL,
|
|
|
|
|
properties_override,
|
libnm: embed private structure in NMSetting and avoid g_type_class_add_private()
Historically, the NMSetting types were in public headers. Theoretically,
that allowed users to subtype our classes. However in practice that was
impossible because they lacked required access to internal functions to
fully create an NMSetting class outside of libnm. And it also was not
useful, because you simply cannot extend libnm by subtyping a libnm
class. And supporting such a use case would be hard and limit what we can
do in libnm.
Having GObject structs in public headers also require that we don't
change it's layout. The ABI of those structs must not change, if anybody
out there was actually subclassing our GObjects.
In libnm 1.34 (commit e46d484fae9e ('libnm: hide NMSetting types from
public headers')) we moved the structs from headers to internal.
This would have caused a compiler error if anybody was using those
struct definitions. However, we still didn't change the ABI/layout so
that we didn't break users who relied on it (for whatever reason).
It doesn't seem there were any affected user. We waited long enough.
Change internal ABI.
No longer use g_type_class_add_private(). Instead, embed the private
structs directly (_NM_GET_PRIVATE()) or indirectly
(_NM_GET_PRIVATE_PTR()) in the object.
The main benefit is for debugging in the debugger, where we can now
easily find the private data. Previously that was so cumbersome to be
effectively impossible.
It's also the fastest possible way, since NM_SETTING_*_GET_PRIVATE()
literally resolves to "&self->_priv" (plus static asserts and
nm_assert() for type checking).
_NM_GET_PRIVATE() also propagates constness and requires that the
argument is a compatible pointer type (at compile time).
Note that g_type_class_add_private() is also deprecated in glib 2.58 and
replaced by G_ADD_PRIVATE(). For one, we still don't rely on 2.58. Also,
G_ADD_PRIVATE() is a worse solution as it supports a usecase that we
don't care for (public structs in headers). _NM_GET_PRIVATE() is still
faster, works with older glib and most importantly: is better for
debugging as you can find the private data from an object pointer.
For NMSettingIPConfig this is rather awkward, because all direct
properties require a common "klass->private_offset". This was however
the case before this change. Nothing new here. And if you ever touch
this and do something wrong, many unit tests will fail. It's almost
impossible to get wrong, albeit it can be confusing to understand.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1773
2023-10-24 19:05:50 +02:00
|
|
|
G_STRUCT_OFFSET(NMSettingConnection, _priv));
|
2014-07-24 08:53:33 -04:00
|
|
|
}
|