fdo-mirrors/NetworkManager
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git synced 2025-12-20 14:00:05 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
NetworkManager/src/libnm-core-impl/nm-setting-connection.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

3031 lines
114 KiB
C
Raw Normal View History

all: update deprecated SPDX license identifiers These SPDX license identifiers are deprecated ([1]). Update them. [1] https://spdx.org/licenses/ sed \ -e '1 s%^/\* SPDX-License-Identifier: \(GPL-2.0\|LGPL-2.1\)+ \*/$%/* SPDX-License-Identifier: \1-or-later */%' \ -e '1,2 s%^\(--\|#\|//\) SPDX-License-Identifier: \(GPL-2.0\|LGPL-2.1\)+$%\1 SPDX-License-Identifier: \2-or-later%' \ -i \ $(git grep -l SPDX-License-Identifier -- \ ':(exclude)shared/c-*/' \ ':(exclude)shared/n-*/' \ ':(exclude)shared/systemd/src' \ ':(exclude)src/systemd/src')
2020-12-23 22:21:36 +01:00
/* SPDX-License-Identifier: LGPL-2.1-or-later */
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/*
all: unify format of our Copyright source code comments ```bash readarray -d '' FILES < <( git ls-files -z \ ':(exclude)po' \ ':(exclude)shared/c-rbtree' \ ':(exclude)shared/c-list' \ ':(exclude)shared/c-siphash' \ ':(exclude)shared/c-stdaux' \ ':(exclude)shared/n-acd' \ ':(exclude)shared/n-dhcp4' \ ':(exclude)src/systemd/src' \ ':(exclude)shared/systemd/src' \ ':(exclude)m4' \ ':(exclude)COPYING*' ) sed \ -e 's/^\(--\|#\| \*\) *\(([cC]) *\)\?Copyright \+\(\(([cC])\) \+\)\?\(\(20\|19\)[0-9][0-9]\) *[-–] *\(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/\1 C1pyright#\5 - \7#\9/' \ -e 's/^\(--\|#\| \*\) *\(([cC]) *\)\?Copyright \+\(\(([cC])\) \+\)\?\(\(20\|19\)[0-9][0-9]\) *[,] *\(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/\1 C2pyright#\5, \7#\9/' \ -e 's/^\(--\|#\| \*\) *\(([cC]) *\)\?Copyright \+\(\(([cC])\) \+\)\?\(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/\1 C3pyright#\5#\7/' \ -e 's/^Copyright \(\(20\|19\)[0-9][0-9]\) \+\([^ ].*\)$/C4pyright#\1#\3/' \ -i \ "${FILES[@]}" echo ">>> untouched Copyright lines" git grep Copyright "${FILES[@]}" echo ">>> Copyright lines with unusual extra" git grep '\<C[0-9]pyright#' "${FILES[@]}" | grep -i reserved sed \ -e 's/\<C[0-9]pyright#\([^#]*\)#\(.*\)$/Copyright (C) \1 \2/' \ -i \ "${FILES[@]}" ``` https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/298
2019-10-01 09:20:35 +02:00
* Copyright (C) 2007 - 2013 Red Hat, Inc.
* Copyright (C) 2007 - 2008 Novell, Inc.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*/
build: move "libnm-core/" to "src/" and split it "libnm-core/" is rather complicated. It provides a static library that is linked into libnm.so and NetworkManager. It also contains public headers (like "nm-setting.h") which are part of public libnm API. Then we have helper libraries ("libnm-core/nm-libnm-core-*/") which only rely on public API of libnm-core, but are themself static libraries that can be used by anybody who uses libnm-core. And "libnm-core/nm-libnm-core-intern" is used by libnm-core itself. Move "libnm-core/" to "src/". But also split it in different directories so that they have a clearer purpose. The goal is to have a flat directory hierarchy. The "src/libnm-core*/" directories correspond to the different modules (static libraries and set of headers that we have). We have different kinds of such modules because of how we combine various code together. The directory layout now reflects this.
2021-02-12 15:01:09 +01:00
#include "libnm-core-impl/nm-default-libnm-core.h"
all: cleanup includes and let "nm-default.h" include "config.h" - All internal source files (except "examples", which are not internal) should include "config.h" first. As also all internal source files should include "nm-default.h", let "config.h" be included by "nm-default.h" and include "nm-default.h" as first in every source file. We already wanted to include "nm-default.h" before other headers because it might contains some fixes (like "nm-glib.h" compatibility) that is required first. - After including "nm-default.h", we optinally allow for including the corresponding header file for the source file at hand. The idea is to ensure that each header file is self contained. - Don't include "config.h" or "nm-default.h" in any header file (except "nm-sd-adapt.h"). Public headers anyway must not include these headers, and internal headers are never included after "nm-default.h", as of the first previous point. - Include all internal headers with quotes instead of angle brackets. In practice it doesn't matter, because in our public headers we must include other headers with angle brackets. As we use our public headers also to compile our interal source files, effectively the result must be the same. Still do it for consistency. - Except for <config.h> itself. Include it with angle brackets as suggested by https://www.gnu.org/software/autoconf/manual/autoconf.html#Configuration-Headers
2016-02-19 14:57:48 +01:00
build: cleanup default includes - "gsystem-local-alloc.h" and <gio/gio.h> are already included via "nm-default.h". No need to include them separately. - include "nm-macros-internal.h" via "nm-default.h" and drop all explict includes. - in the modified files, ensure that we always include "config.h" and "nm-default.h" first. As second, include the header file for the current source file (if applicable). Then follow external includes and finally internal nm includes. - include nm headers inside source code files with quotes - internal header files don't need to include default headers. They can savely assume that "nm-default.h" is already included and with it glib, nm-glib.h, nm-macros-internal.h, etc.
2016-02-12 14:44:52 +01:00
#include "nm-setting-connection.h"
libnm: normalize "connection.uuid" For NetworkManager profiles, "connection.uuid" is the identifier of the profile. It is supposed to be a UUID, however: - the UUID was not ensured to be all-lower case. We should make sure that our UUIDs are in a consistent manner, so that users can rely on the format of the string. - the UUID was never actually interpreted as a UUID. It only was some opaque string, that we use as identifier. We had nm_utils_is_uuid() which checks that the format is valid, however that did not fully validate the format, like it would accept "----7daf444dd78741a59e1ef1b3c8b1c0e8" and "549fac10a25f4bcc912d1ae688c2b4987daf444d" (40 hex characters). Both invalid UUIDs and non-normalized UUID should be normalized. We don't want to break existing profiles that use such UUIDs, thus we don't outright reject them. Let's instead mangle them during nm_connection_normalize().
2021-05-02 22:42:51 +02:00
#include "libnm-glib-aux/nm-uuid.h"
build: move "libnm-core/" to "src/" and split it "libnm-core/" is rather complicated. It provides a static library that is linked into libnm.so and NetworkManager. It also contains public headers (like "nm-setting.h") which are part of public libnm API. Then we have helper libraries ("libnm-core/nm-libnm-core-*/") which only rely on public API of libnm-core, but are themself static libraries that can be used by anybody who uses libnm-core. And "libnm-core/nm-libnm-core-intern" is used by libnm-core itself. Move "libnm-core/" to "src/". But also split it in different directories so that they have a clearer purpose. The goal is to have a flat directory hierarchy. The "src/libnm-core*/" directories correspond to the different modules (static libraries and set of headers that we have). We have different kinds of such modules because of how we combine various code together. The directory layout now reflects this.
2021-02-12 15:01:09 +01:00
#include "libnm-core-aux-intern/nm-common-macros.h"
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
#include "nm-utils.h"
libnm-core: change list-of-string and array-of-string properties to G_TYPE_STRV Change all DBUS_TYPE_G_LIST_OF_STRING and DBUS_TYPE_G_ARRAY_OF_STRING properties to G_TYPE_STRV, and update everything accordingly. (This doesn't actually require using _nm_setting_class_transform_property(); dbus-glib is happy to transform between 'as' and G_TYPE_STRV.)
2014-08-21 13:19:53 -04:00
#include "nm-utils-private.h"
libnm: add autoconnect-slaves property to NMSettingConnection The property is used for controlling whether slaves should be brought up with a master connection. If 0, activating the master will not activate slaves. But if set to 1, activating the master will bring up slaves as well. The property can have the third state (-1), meaning that the value is default. That is either a value set in the configuration file for the property, or 0.
2015-05-06 10:54:35 +02:00
#include "nm-core-enum-types.h"
libnm-core: make nm_setting_verify() take an NMConnection nm_setting_verify() took a GSList of other NMSettings, but really it would just be simpler all around to pass the NMConnection instead... This means that several formerly NMSetting-branded functions that operated on lists-of-settings now get replaced with NMConnection-branded functions instead.
2014-10-21 22:30:31 -04:00
#include "nm-connection-private.h"
libnm-core: add nm-core-types.h, remove cross-includes Add nm-core-types.h, typedefing all of the GObject types in libnm-core; this is needed so that nm-setting.h can reference NMConnection in addition to nm-connection.h referencing NMSetting. Removing the cross-includes from the various headers causes lots of fallout elsewhere. (In particular, nm-utils.h used to include nm-connection.h, which included every setting header, so any file that included nm-utils.h automatically got most of the rest of libnm-core without needing to pay attention to specifics.) Fix this up by including nm-core-internal.h from those files that are now missing includes.
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"
build: move "shared/systemd" to "src/libnm-systemd-shared"
2021-02-18 08:13:35 +01:00
#include "libnm-systemd-shared/nm-sd-utils-shared.h"
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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.
**/
libnm-core: reorder code in settings Order the code in our common way. No other changes. - ensure to include the main header first (directly after "nm-default.h"). - reorder function definitions: get_property(), set_property(), *_init(), *_new(), finalize(), *_class_init().
2019-01-11 08:32:54 +01:00
/*****************************************************************************/
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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,
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
char *item;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
} Permission;
libnm-core: reorder code in settings Order the code in our common way. No other changes. - ensure to include the main header first (directly after "nm-default.h"). - reorder function definitions: get_property(), set_property(), *_init(), *_new(), finalize(), *_class_init().
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,
connection: deprecate the NMSettingConnection Master property To embrace inclusive language, deprecate the NMSettingConnection Master property and introduce Controller property.
2023-11-29 14:43:43 +01:00
PROP_CONTROLLER,
libnm-core: reorder code in settings Order the code in our common way. No other changes. - ensure to include the main header first (directly after "nm-default.h"). - reorder function definitions: get_property(), set_property(), *_init(), *_new(), finalize(), *_class_init().
2019-01-11 08:32:54 +01:00
PROP_SLAVE_TYPE,
connection: deprecate the NMSettingConnection slave-type property To embrace inclusive language, deprecate the NMSettingConnection slave-type property and introduce port-type property. Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
2024-01-16 13:58:11 +01:00
PROP_PORT_TYPE,
libnm-core: reorder code in settings Order the code in our common way. No other changes. - ensure to include the main header first (directly after "nm-default.h"). - reorder function definitions: get_property(), set_property(), *_init(), *_new(), finalize(), *_class_init().
2019-01-11 08:32:54 +01:00
PROP_AUTOCONNECT_SLAVES,
PROP_SECONDARIES,
PROP_GATEWAY_PING_TIMEOUT,
PROP_METERED,
PROP_LLDP,
PROP_MDNS,
PROP_LLMNR,
libnm-core: Add connection.dns-over-tls property
2021-10-03 19:16:01 +02:00
PROP_DNS_OVER_TLS,
all: add NMMptcpFlags and connection.mptcp-flags property
2022-07-18 21:24:09 +02:00
PROP_MPTCP_FLAGS,
libnm-core: reorder code in settings Order the code in our common way. No other changes. - ensure to include the main header first (directly after "nm-default.h"). - reorder function definitions: get_property(), set_property(), *_init(), *_new(), finalize(), *_class_init().
2019-01-11 08:32:54 +01:00
PROP_STABLE_ID,
PROP_AUTH_RETRIES,
libnm,cli,ifcfg-rh: add connection:wait-device-timeout property Initscripts already honor the DEVTIMEOUT variable (rh #1171917). Don't make this a property only supported by initscripts. Every useful property should also be supported by keyfile and it should be accessible via D-Bus. Also, I will soon drop NMSIfcfgConnection, so handling this would require extra code. It's easier when DEVTIMEOUT is a regular property of the connection profile. The property is not yet implemented. ifcfg-rh still uses the old implementation, and keyfile is not yet adjusted. Since both keyfile and ifcfg-rh will both be rewritten soon, this property will be implemented then.
2019-07-01 10:01:28 +02:00
PROP_WAIT_DEVICE_TIMEOUT,
libnm: support wait-activation-delay property The property wait-activation-delay will delay the activation of an interface the specified amount of milliseconds. Please notice that it could be delayed some milliseconds more due to other events in NetworkManager. This could be used in multiple scenarios where the user needs to define an arbitrary delay e.g LACP bond configure where the LACP negotiation takes a few seconds and traffic is not allowed, so they would like to use nm-online and a setting configured with this new property to wait some seconds. Therefore, when nm-online is finished, LACP bond should be ready to receive traffic. The delay will happen right before the device is ready to be activated. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1248 https://bugzilla.redhat.com/show_bug.cgi?id=2008337
2022-05-27 12:36:29 +02:00
PROP_MUD_URL,
PROP_WAIT_ACTIVATION_DELAY, );
libnm-core: reorder code in settings Order the code in our common way. No other changes. - ensure to include the main header first (directly after "nm-default.h"). - reorder function definitions: get_property(), set_property(), *_init(), *_new(), finalize(), *_class_init().
2019-01-11 08:32:54 +01:00
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
typedef struct {
libnm: rework strv properties of NMSetting as "direct" properties Make use of direct strv property in some cases. It doesn't work for other cases yet, because they are implemented differently, and porting them is more effort and needs to be done one by one. The goal is to have a unified, standard implementation for our properties. One that requires a minimal amount of property-specific code. For strv properties, that is a bit more cumbersome, because usually there are multiple C accessor functions. Still, make an effort to have a "direct" strv property. What this also gives, is that we no longer need to clone the strv array for various operations. We know how to access the data, and can do it directly without g_object_get()/g_object_set().
2022-01-24 17:24:25 +01:00
GArray *permissions;
NMValueStrv secondaries;
char *id;
char *uuid;
char *stable_id;
char *interface_name;
char *type;
connection: deprecate the NMSettingConnection Master property To embrace inclusive language, deprecate the NMSettingConnection Master property and introduce Controller property.
2023-11-29 14:43:43 +01:00
char *controller;
connection: deprecate the NMSettingConnection slave-type property To embrace inclusive language, deprecate the NMSettingConnection slave-type property and introduce port-type property. Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
2024-01-16 13:58:11 +01:00
char *port_type;
libnm: rework strv properties of NMSetting as "direct" properties Make use of direct strv property in some cases. It doesn't work for other cases yet, because they are implemented differently, and porting them is more effort and needs to be done one by one. The goal is to have a unified, standard implementation for our properties. One that requires a minimal amount of property-specific code. For strv properties, that is a bit more cumbersome, because usually there are multiple C accessor functions. Still, make an effort to have a "direct" strv property. What this also gives, is that we no longer need to clone the strv array for various operations. We know how to access the data, and can do it directly without g_object_get()/g_object_set().
2022-01-24 17:24:25 +01:00
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;
libnm: support wait-activation-delay property The property wait-activation-delay will delay the activation of an interface the specified amount of milliseconds. Please notice that it could be delayed some milliseconds more due to other events in NetworkManager. This could be used in multiple scenarios where the user needs to define an arbitrary delay e.g LACP bond configure where the LACP negotiation takes a few seconds and traffic is not allowed, so they would like to use nm-online and a setting configured with this new property to wait some seconds. Therefore, when nm-online is finished, LACP bond should be ready to receive traffic. The delay will happen right before the device is ready to be activated. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1248 https://bugzilla.redhat.com/show_bug.cgi?id=2008337
2022-05-27 12:36:29 +02:00
gint32 wait_activation_delay;
all: add NMMptcpFlags and connection.mptcp-flags property
2022-07-18 21:24:09 +02:00
guint32 mptcp_flags;
libnm: rework strv properties of NMSetting as "direct" properties Make use of direct strv property in some cases. It doesn't work for other cases yet, because they are implemented differently, and porting them is more effort and needs to be done one by one. The goal is to have a unified, standard implementation for our properties. One that requires a minimal amount of property-specific code. For strv properties, that is a bit more cumbersome, because usually there are multiple C accessor functions. Still, make an effort to have a "direct" strv property. What this also gives, is that we no longer need to clone the strv array for various operations. We know how to access the data, and can do it directly without g_object_get()/g_object_set().
2022-01-24 17:24:25 +01:00
guint32 gateway_ping_timeout;
bool autoconnect;
bool read_only;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
} NMSettingConnectionPrivate;
libnm: hide NMSetting types from public headers When subclassing a GObject type, the class and object structs must be available and defined in the header. For libnm, and in particular for NMSetting classes, we don't want users to subclass NMSetting. It also doesn't work, because libnm has internal code that is necessary to hook up the NMSetting class. You cannot define your own type and make it work together with libnm. Having the structs in public headers limits what we can do with them. For example, we could embed the private data directly in the structures and avoid the additional indirection. This is an API break, but for something that most likely nobody cares about. Or better, nobody should care about. API is not what is accidentally defined in a header, API was the library provides to meaningfully use. Subclassing these types is not meaningful and was only accidentally possible so far. Only hide the structs for now. More cleanup is possible later. We shall however aim to keep the padding and struct layout to not also break ABI. (cherry picked from commit e46d484fae9e04c3dabf9fad7542c5d7a3dedf0d)
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;
libnm: hide NMSetting types from public headers When subclassing a GObject type, the class and object structs must be available and defined in the header. For libnm, and in particular for NMSetting classes, we don't want users to subclass NMSetting. It also doesn't work, because libnm has internal code that is necessary to hook up the NMSetting class. You cannot define your own type and make it work together with libnm. Having the structs in public headers limits what we can do with them. For example, we could embed the private data directly in the structures and avoid the additional indirection. This is an API break, but for something that most likely nobody cares about. Or better, nobody should care about. API is not what is accidentally defined in a header, API was the library provides to meaningfully use. Subclassing these types is not meaningful and was only accidentally possible so far. Only hide the structs for now. More cleanup is possible later. We shall however aim to keep the padding and struct layout to not also break ABI. (cherry picked from commit e46d484fae9e04c3dabf9fad7542c5d7a3dedf0d)
2021-06-11 00:27:31 +02:00
};
struct _NMSettingConnectionClass {
NMSettingClass parent;
};
libnm-core: reorder code in settings Order the code in our common way. No other changes. - ensure to include the main header first (directly after "nm-default.h"). - reorder function definitions: get_property(), set_property(), *_init(), *_new(), finalize(), *_class_init().
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)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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". */
}
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
ulen = last_colon - str;
} else
ulen = strlen(str);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
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;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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 ?: "");
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
all: modify line separator comments to be 80 chars wide sed 's#^/\*\{5\}\*\+/$#/*****************************************************************************/#' $(git grep -l '\*\{5\}' | grep '\.[hc]$') -i
2016-10-02 18:22:50 +02:00
/*****************************************************************************/
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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;
}
libnm: add NMSettingConnection:stable-id property This new property be used as token to generate stable-ids instead of the connection's UUID. Later, this will be used by ipv6.addr-gen-mode=stable-privacy, ethernet.cloned-mac-address=stable, and wifi.cloned-mac-address=stable setting. Those generate stable addresses based on the connection's UUID, but allow to use the stable-id instead. This allows multiple connections to generate the same addresses -- on the same machine, because in the above cases a machine dependant key is also hashed.
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;
}
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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
*
all: fix typo 'entires' -> 'entries' (cherry picked from commit a4cbfe6f0a1fe19ddf7d98cf7a0e1914fe085aff)
2017-05-05 14:11:05 +02:00
* Returns the number of entries in the #NMSettingConnection:permissions
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
* property of this setting.
*
all: fix typo 'entires' -> 'entries' (cherry picked from commit a4cbfe6f0a1fe19ddf7d98cf7a0e1914fe085aff)
2017-05-05 14:11:05 +02:00
* Returns: the number of permissions entries
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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".
docs: misc. typos pt2 Remainder of typos found using `codespell -q 3 --skip="./shared,./src/systemd,*.po" -I ../NetworkManager-word-whitelist.txt` whereby whitelist consists of: ``` ans busses cace cna conexant crasher iff liftime creat nd sav technik uint ``` https://github.com/NetworkManager/NetworkManager/pull/205
2018-09-15 07:20:54 -04:00
* @out_pitem: on return, the permission item (formatted according to @ptype, see
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const char **out_ptype,
const char **out_pitem,
const char **out_detail)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
NMSettingConnectionPrivate *priv;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
Permission *permission;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
all: use nm_g_array_{index,first,last,index_p}() instead of g_array_index() These variants provide additional nm_assert() checks, and are thus preferable. Note that we cannot just blindly replace &g_array_index() with &nm_g_array_index(), because the latter would not allow getting a pointer at index [arr->len]. That might be a valid (though uncommon) usecase. The correct replacement of &g_array_index() is thus nm_g_array_index_p(). I checked the code manually and replaced uses of nm_g_array_index_p() with &nm_g_array_index(), if that was a safe thing to do. The latter seems preferable, because it is familar to &g_array_index().
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);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
return TRUE;
}
core: avoid getpwuid() unless necessary in permission check Most profiles don't have "connection.permissions" set. Avoid resolving the UID to the name via getpwuid() (in nm_auth_is_subject_in_acl()), until we know that we require it.
2023-10-23 12:11:33 +02:00
static gboolean
_permissions_user_allowed(NMSettingConnection *setting, const char *uname, gulong uid)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
libnm: use nm_getpwuid() in _permissions_user_allowed() No need to clone the string again. Use nm_getpwuid() directly and avoid an additional clone.
2023-10-23 13:19:26 +02:00
gs_free struct passwd *pw = NULL;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm: fix broken assertion in _permissions_user_allowed() Fixes: b2b2823c53b9 ('core: avoid getpwuid() unless necessary in permission check')
2023-11-15 10:38:18 +01:00
nm_assert(NM_IS_SETTING_CONNECTION(setting));
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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 */
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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
}
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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++) {
all: use nm_g_array_{index,first,last,index_p}() instead of g_array_index() These variants provide additional nm_assert() checks, and are thus preferable. Note that we cannot just blindly replace &g_array_index() with &nm_g_array_index(), because the latter would not allow getting a pointer at index [arr->len]. That might be a valid (though uncommon) usecase. The correct replacement of &g_array_index() is thus nm_g_array_index_p(). I checked the code manually and replaced uses of nm_g_array_index_p() with &nm_g_array_index(), if that was a safe thing to do. The latter seems preferable, because it is familar to &g_array_index().
2022-09-08 12:05:56 +02:00
const Permission *permission = &nm_g_array_index(priv->permissions, Permission, i);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
core: avoid getpwuid() unless necessary in permission check Most profiles don't have "connection.permissions" set. Avoid resolving the UID to the name via getpwuid() (in nm_auth_is_subject_in_acl()), until we know that we require it.
2023-10-23 12:11:33 +02:00
if (permission->ptype != PERM_TYPE_USER)
continue;
if (!uname) {
libnm: use nm_getpwuid() in _permissions_user_allowed() No need to clone the string again. Use nm_getpwuid() directly and avoid an additional clone.
2023-10-23 13:19:26 +02:00
if (uid != G_MAXULONG) {
pw = nm_getpwuid(uid);
uname = nm_passwd_name(pw);
}
if (!uname)
core: avoid getpwuid() unless necessary in permission check Most profiles don't have "connection.permissions" set. Avoid resolving the UID to the name via getpwuid() (in nm_auth_is_subject_in_acl()), until we know that we require it.
2023-10-23 12:11:33 +02:00
return FALSE;
}
if (nm_streq(permission->item, uname))
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
return TRUE;
}
return FALSE;
}
core: avoid getpwuid() unless necessary in permission check Most profiles don't have "connection.permissions" set. Avoid resolving the UID to the name via getpwuid() (in nm_auth_is_subject_in_acl()), until we know that we require it.
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);
}
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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
doc: replace all (allow-none) annotations by (optional) and/or (nullable) The (allow-none) annotation is deprecated since a long time now, it is better to use (nullable) and/or (optional) which clarifies what it means with the (out) annotation. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1551
2023-03-01 01:21:38 +01:00
* @detail: (nullable): unused at this time; must be %NULL
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*/
gboolean
nm_setting_connection_add_permission(NMSettingConnection *setting,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const char *ptype,
const char *pitem,
const char *detail)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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++) {
all: use nm_g_array_{index,first,last,index_p}() instead of g_array_index() These variants provide additional nm_assert() checks, and are thus preferable. Note that we cannot just blindly replace &g_array_index() with &nm_g_array_index(), because the latter would not allow getting a pointer at index [arr->len]. That might be a valid (though uncommon) usecase. The correct replacement of &g_array_index() is thus nm_g_array_index_p(). I checked the code manually and replaced uses of nm_g_array_index_p() with &nm_g_array_index(), if that was a safe thing to do. The latter seems preferable, because it is familar to &g_array_index().
2022-09-08 12:05:56 +02:00
const Permission *permission = &nm_g_array_index(priv->permissions, Permission, i);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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);
libnm-core: cleanup NMSetting's class initialization Unify the coding style for class-init functions in libnm-core. Also make use of obj_properties, NM_GOBJECT_PROPERTIES_DEFINE(), and _notify().
2019-01-11 08:28:26 +01:00
_notify(setting, PROP_PERMISSIONS);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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
doc: replace all (allow-none) annotations by (optional) and/or (nullable) The (allow-none) annotation is deprecated since a long time now, it is better to use (nullable) and/or (optional) which clarifies what it means with the (out) annotation. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1551
2023-03-01 01:21:38 +01:00
* @detail: (nullable): unused at this time; must be %NULL
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const char *ptype,
const char *pitem,
const char *detail)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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++) {
all: use nm_g_array_{index,first,last,index_p}() instead of g_array_index() These variants provide additional nm_assert() checks, and are thus preferable. Note that we cannot just blindly replace &g_array_index() with &nm_g_array_index(), because the latter would not allow getting a pointer at index [arr->len]. That might be a valid (though uncommon) usecase. The correct replacement of &g_array_index() is thus nm_g_array_index_p(). I checked the code manually and replaced uses of nm_g_array_index_p() with &nm_g_array_index(), if that was a safe thing to do. The latter seems preferable, because it is familar to &g_array_index().
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;
}
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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;
}
libnm: add NMSettingConnection:autoconnect-priority setting The autoconnect priority has only any relevance, if the connection is autoconnect too. The priority defaults to zero, with higher numbers meaning preferred. The valid range is limited to [-999,999]. Signed-off-by: Thomas Haller <thaller@redhat.com>
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
libnm: add NMSettingConnection:autoconnect-priority setting The autoconnect priority has only any relevance, if the connection is autoconnect too. The priority defaults to zero, with higher numbers meaning preferred. The valid range is limited to [-999,999]. Signed-off-by: Thomas Haller <thaller@redhat.com>
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;
}
libnm-core: introduce connection.autoconnect-retries property While technically it's already possible to implement a fail-over mechanism using multiple connections (for example, defining a higher priority DHCP connection with short DHCP timeout and a lower priority one with static address), in practice this doesn't work well as we try to autoactivate each connection 4 times before switching to the next one. Introduce a connection.autoconnect-retries property that can be used to change the number of retries. The special value 0 means infinite and can be used to try the connection forever. A -1 value means the global configured default, which is equal to 4 unless overridden. https://bugzilla.gnome.org/show_bug.cgi?id=763524
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
libnm-core: introduce connection.autoconnect-retries property While technically it's already possible to implement a fail-over mechanism using multiple connections (for example, defining a higher priority DHCP connection with short DHCP timeout and a lower priority one with static address), in practice this doesn't work well as we try to autoactivate each connection 4 times before switching to the next one. Introduce a connection.autoconnect-retries property that can be used to change the number of retries. The special value 0 means infinite and can be used to try the connection forever. A -1 value means the global configured default, which is equal to 4 unless overridden. https://bugzilla.gnome.org/show_bug.cgi?id=763524
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;
}
all: move setting 802-1x.auth-retries to connection.auth-retries The number of authentication retires is useful also for passwords aside 802-1x settings. For example, src/devices/wifi/nm-device-wifi.c also has a retry counter and uses a hard-coded value of 3. Move the setting, so that it can be used in general. Although it is still not implemented for other settings. This is an API and ABI break.
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
all: move setting 802-1x.auth-retries to connection.auth-retries The number of authentication retires is useful also for passwords aside 802-1x settings. For example, src/devices/wifi/nm-device-wifi.c also has a retry counter and uses a hard-coded value of 3. Move the setting, so that it can be used in general. Although it is still not implemented for other settings. This is an API and ABI break.
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;
}
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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;
}
libnm: implement serialization options (inject timestamp/seen-bssids) for nm_connection_to_dbus_full()
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)
libnm: implement serialization options (inject timestamp/seen-bssids) for nm_connection_to_dbus_full()
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);
}
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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
libnm: make "connection.read-only" as deprecated This has no more meaning, and is always false.
2023-03-14 08:48:07 +01:00
*
* Deprecated: 1.44: This property is deprecated and has no meaning.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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.
connection: deprecate the NMSettingConnection Master property To embrace inclusive language, deprecate the NMSettingConnection Master property and introduce Controller property.
2023-11-29 14:43:43 +01:00
*
* Deprecated: 1.46. Use nm_setting_connection_get_controller() instead which
* is just an alias.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*/
const char *
nm_setting_connection_get_master(NMSettingConnection *setting)
connection: deprecate the NMSettingConnection Master property To embrace inclusive language, deprecate the NMSettingConnection Master property and introduce Controller property.
2023-11-29 14:43:43 +01:00
{
return nm_setting_connection_get_controller(setting);
}
/**
* nm_setting_connection_get_controller:
* @setting: the #NMSettingConnection
*
* Returns the #NMSettingConnection:controller property of the connection.
*
* Returns: interface name of the controller device or UUID of the controller
* connection.
*
* Since: 1.46
*/
const char *
nm_setting_connection_get_controller(NMSettingConnection *setting)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), NULL);
connection: deprecate the NMSettingConnection Master property To embrace inclusive language, deprecate the NMSettingConnection Master property and introduce Controller property.
2023-11-29 14:43:43 +01:00
return NM_SETTING_CONNECTION_GET_PRIVATE(setting)->controller;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
connection: deprecate the NMSettingConnection slave-type property To embrace inclusive language, deprecate the NMSettingConnection slave-type property and introduce port-type property. Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
2024-01-16 13:58:11 +01:00
/**
* nm_setting_connection_get_port_type:
* @setting: the #NMSettingConnection
*
* Returns the #NMSettingConnection:port-type property of the connection.
*
* Returns: the type of port this connection is, if any.
*
* Since: 1.46
*/
const char *
nm_setting_connection_get_port_type(NMSettingConnection *setting)
{
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), NULL);
return NM_SETTING_CONNECTION_GET_PRIVATE(setting)->port_type;
}
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/**
* 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
connection: deprecate the NMSettingConnection slave-type property To embrace inclusive language, deprecate the NMSettingConnection slave-type property and introduce port-type property. Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
2024-01-16 13:58:11 +01:00
*
* Deprecated: 1.46. Use nm_setting_connection_get_port_type() instead which
* is just an alias.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*/
const char *
nm_setting_connection_get_slave_type(NMSettingConnection *setting)
{
connection: deprecate the NMSettingConnection slave-type property To embrace inclusive language, deprecate the NMSettingConnection slave-type property and introduce port-type property. Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
2024-01-16 13:58:11 +01:00
return nm_setting_connection_get_port_type(setting);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
/**
* 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
connection: deprecate the NMSettingConnection slave-type property To embrace inclusive language, deprecate the NMSettingConnection slave-type property and introduce port-type property. Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
2024-01-16 13:58:11 +01:00
*
* Deprecated: 1.46.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*/
gboolean
nm_setting_connection_is_slave_type(NMSettingConnection *setting, const char *type)
{
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), FALSE);
connection: drop the usage of nm_setting_connection_is_slave_type() As the function is deperecated, drop the usage of it. In addition replace the !g_strcmp0() usage for nm_streq0().
2024-01-19 16:02:40 +01:00
return nm_streq0(NM_SETTING_CONNECTION_GET_PRIVATE(setting)->port_type, type);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
libnm,cli,ifcfg-rh: add connection:wait-device-timeout property Initscripts already honor the DEVTIMEOUT variable (rh #1171917). Don't make this a property only supported by initscripts. Every useful property should also be supported by keyfile and it should be accessible via D-Bus. Also, I will soon drop NMSIfcfgConnection, so handling this would require extra code. It's easier when DEVTIMEOUT is a regular property of the connection profile. The property is not yet implemented. ifcfg-rh still uses the old implementation, and keyfile is not yet adjusted. Since both keyfile and ifcfg-rh will both be rewritten soon, this property will be implemented then.
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.
libnm,cli,ifcfg-rh: add connection:wait-device-timeout property Initscripts already honor the DEVTIMEOUT variable (rh #1171917). Don't make this a property only supported by initscripts. Every useful property should also be supported by keyfile and it should be accessible via D-Bus. Also, I will soon drop NMSIfcfgConnection, so handling this would require extra code. It's easier when DEVTIMEOUT is a regular property of the connection profile. The property is not yet implemented. ifcfg-rh still uses the old implementation, and keyfile is not yet adjusted. Since both keyfile and ifcfg-rh will both be rewritten soon, this property will be implemented then.
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;
}
libnm: support wait-activation-delay property The property wait-activation-delay will delay the activation of an interface the specified amount of milliseconds. Please notice that it could be delayed some milliseconds more due to other events in NetworkManager. This could be used in multiple scenarios where the user needs to define an arbitrary delay e.g LACP bond configure where the LACP negotiation takes a few seconds and traffic is not allowed, so they would like to use nm-online and a setting configured with this new property to wait some seconds. Therefore, when nm-online is finished, LACP bond should be ready to receive traffic. The delay will happen right before the device is ready to be activated. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1248 https://bugzilla.redhat.com/show_bug.cgi?id=2008337
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;
}
libnm: add autoconnect-slaves property to NMSettingConnection The property is used for controlling whether slaves should be brought up with a master connection. If 0, activating the master will not activate slaves. But if set to 1, activating the master will bring up slaves as well. The property can have the third state (-1), meaning that the value is default. That is either a value set in the configuration file for the property, or 0.
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
libnm: add autoconnect-slaves property to NMSettingConnection The property is used for controlling whether slaves should be brought up with a master connection. If 0, activating the master will not activate slaves. But if set to 1, activating the master will bring up slaves as well. The property can have the third state (-1), meaning that the value is default. That is either a value set in the configuration file for the property, or 0.
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)
{
libnm: rework strv properties of NMSetting as "direct" properties Make use of direct strv property in some cases. It doesn't work for other cases yet, because they are implemented differently, and porting them is more effort and needs to be done one by one. The goal is to have a unified, standard implementation for our properties. One that requires a minimal amount of property-specific code. For strv properties, that is a bit more cumbersome, because usually there are multiple C accessor functions. Still, make an effort to have a "direct" strv property. What this also gives, is that we no longer need to clone the strv array for various operations. We know how to access the data, and can do it directly without g_object_get()/g_object_set().
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
}
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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);
libnm: rework strv properties of NMSetting as "direct" properties Make use of direct strv property in some cases. It doesn't work for other cases yet, because they are implemented differently, and porting them is more effort and needs to be done one by one. The goal is to have a unified, standard implementation for our properties. One that requires a minimal amount of property-specific code. For strv properties, that is a bit more cumbersome, because usually there are multiple C accessor functions. Still, make an effort to have a "direct" strv property. What this also gives, is that we no longer need to clone the strv array for various operations. We know how to access the data, and can do it directly without g_object_get()/g_object_set().
2022-01-24 17:24:25 +01:00
return nm_g_array_len(NM_SETTING_CONNECTION_GET_PRIVATE(setting)->secondaries.arr);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
/**
* nm_setting_connection_get_secondary:
* @setting: the #NMSettingConnection
libnm: use GArray to track "connection.secondaries" property instead of GSList GSList requires an additional allocation for the container struct for each element. Also, it does not have O(1) direct access. It's a pretty bad data structure, especially if the underlying data is in form of a strv array. Use a GArray instead and the nm_strvarray_*() helpers.
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.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
*
libnm: use GArray to track "connection.secondaries" property instead of GSList GSList requires an additional allocation for the container struct for each element. Also, it does not have O(1) direct access. It's a pretty bad data structure, especially if the underlying data is in form of a strv array. Use a GArray instead and the nm_strvarray_*() helpers.
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.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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);
libnm: use checked strvarray getter in api functions https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1765
2023-10-11 12:34:22 +02:00
return nm_strvarray_get_idxnull_or_greturn(
NM_SETTING_CONNECTION_GET_PRIVATE(setting)->secondaries.arr,
idx);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
dhcp: add support for MUD URL (RFC 8520) [thaller@redhat.com: rewritten commit message] https://tools.ietf.org/html/rfc8520 https://blog.apnic.net/2019/05/14/protecting-the-internet-of-things-with-mud/ https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/402 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/463
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.
libnm: fix API version annotation for nm_setting_connection_get_mud_url()
2020-04-24 09:20:25 +02:00
*
* Since: 1.26
dhcp: add support for MUD URL (RFC 8520) [thaller@redhat.com: rewritten commit message] https://tools.ietf.org/html/rfc8520 https://blog.apnic.net/2019/05/14/protecting-the-internet-of-things-with-mud/ https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/402 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/463
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;
}
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/**
* nm_setting_connection_add_secondary:
* @setting: the #NMSettingConnection
* @sec_uuid: the secondary connection UUID to add
*
docs: misc. typos pt2 Remainder of typos found using `codespell -q 3 --skip="./shared,./src/systemd,*.po" -I ../NetworkManager-word-whitelist.txt` whereby whitelist consists of: ``` ans busses cace cna conexant crasher iff liftime creat nd sav technik uint ``` https://github.com/NetworkManager/NetworkManager/pull/205
2018-09-15 07:20:54 -04:00
* Adds a new secondary connection UUID to the setting.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), FALSE);
libnm: don't reject empty strings in add/remove API For example for NM_SETTING_CONNECTION_SECONDARIES, the user can set the GObject property to a string list that includes empty strings. The C accessors (add/remove-by-value) should also accept any strings that are accepted otherwise. Asserting against empty strings is wrong. If the setting wants to reject empty strings, then it should use verify().
2021-06-02 14:00:46 +02:00
g_return_val_if_fail(sec_uuid, FALSE);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
priv = NM_SETTING_CONNECTION_GET_PRIVATE(setting);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: use nm_strvarray_*() helpers for strv properties We have many properties, and we aim that they have a small set of "types". The purpose is that we can treat similar properties (with the same type) alike. One type are "direct" strv properties. Those still require some C functions, like get-length(), clear(), add(), get-at-index(). The implementation of those functions should also be similar, so that strv properties behave similar. For that, make use of helper functions, so that little duplicate logic is there. Use some new nm_strvarray_*() functions, and unify/cleanup some code. All related to strv properties in NMSetting classes.
2023-10-26 13:37:34 +02:00
if (!nm_strvarray_ensure_and_add_unique(&priv->secondaries.arr, sec_uuid))
libnm: use GArray to track "connection.secondaries" property instead of GSList GSList requires an additional allocation for the container struct for each element. Also, it does not have O(1) direct access. It's a pretty bad data structure, especially if the underlying data is in form of a strv array. Use a GArray instead and the nm_strvarray_*() helpers.
2021-06-02 14:19:23 +02:00
return FALSE;
libnm-core: cleanup NMSetting's class initialization Unify the coding style for class-init functions in libnm-core. Also make use of obj_properties, NM_GOBJECT_PROPERTIES_DEFINE(), and _notify().
2019-01-11 08:28:26 +01:00
_notify(setting, PROP_SECONDARIES);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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
*
all: fix minor typos https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/565
2020-07-04 11:37:01 +03:00
* Removes the secondary connection UUID at index @idx.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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);
libnm: rework strv properties of NMSetting as "direct" properties Make use of direct strv property in some cases. It doesn't work for other cases yet, because they are implemented differently, and porting them is more effort and needs to be done one by one. The goal is to have a unified, standard implementation for our properties. One that requires a minimal amount of property-specific code. For strv properties, that is a bit more cumbersome, because usually there are multiple C accessor functions. Still, make an effort to have a "direct" strv property. What this also gives, is that we no longer need to clone the strv array for various operations. We know how to access the data, and can do it directly without g_object_get()/g_object_set().
2022-01-24 17:24:25 +01:00
g_return_if_fail(idx < nm_g_array_len(priv->secondaries.arr));
libnm: use GArray to track "connection.secondaries" property instead of GSList GSList requires an additional allocation for the container struct for each element. Also, it does not have O(1) direct access. It's a pretty bad data structure, especially if the underlying data is in form of a strv array. Use a GArray instead and the nm_strvarray_*() helpers.
2021-06-02 14:19:23 +02:00
libnm: use nm_strvarray_*() helpers for strv properties We have many properties, and we aim that they have a small set of "types". The purpose is that we can treat similar properties (with the same type) alike. One type are "direct" strv properties. Those still require some C functions, like get-length(), clear(), add(), get-at-index(). The implementation of those functions should also be similar, so that strv properties behave similar. For that, make use of helper functions, so that little duplicate logic is there. Use some new nm_strvarray_*() functions, and unify/cleanup some code. All related to strv properties in NMSetting classes.
2023-10-26 13:37:34 +02:00
nm_strvarray_remove_index(priv->secondaries.arr, idx);
libnm-core: cleanup NMSetting's class initialization Unify the coding style for class-init functions in libnm-core. Also make use of obj_properties, NM_GOBJECT_PROPERTIES_DEFINE(), and _notify().
2019-01-11 08:28:26 +01:00
_notify(setting, PROP_SECONDARIES);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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
*
all: fix minor typos https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/565
2020-07-04 11:37:01 +03:00
* Removes the secondary connection UUID @sec_uuid.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
g_return_val_if_fail(NM_IS_SETTING_CONNECTION(setting), FALSE);
libnm: don't reject empty strings in add/remove API For example for NM_SETTING_CONNECTION_SECONDARIES, the user can set the GObject property to a string list that includes empty strings. The C accessors (add/remove-by-value) should also accept any strings that are accepted otherwise. Asserting against empty strings is wrong. If the setting wants to reject empty strings, then it should use verify().
2021-06-02 14:00:46 +02:00
g_return_val_if_fail(sec_uuid, FALSE);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
priv = NM_SETTING_CONNECTION_GET_PRIVATE(setting);
libnm: use GArray to track "connection.secondaries" property instead of GSList GSList requires an additional allocation for the container struct for each element. Also, it does not have O(1) direct access. It's a pretty bad data structure, especially if the underlying data is in form of a strv array. Use a GArray instead and the nm_strvarray_*() helpers.
2021-06-02 14:19:23 +02:00
libnm: use nm_strvarray_*() helpers for strv properties We have many properties, and we aim that they have a small set of "types". The purpose is that we can treat similar properties (with the same type) alike. One type are "direct" strv properties. Those still require some C functions, like get-length(), clear(), add(), get-at-index(). The implementation of those functions should also be similar, so that strv properties behave similar. For that, make use of helper functions, so that little duplicate logic is there. Use some new nm_strvarray_*() functions, and unify/cleanup some code. All related to strv properties in NMSetting classes.
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;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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;
}
libnm-core: add 'metered' property to NMSettingConnection Add a 'metered' enum property to NMSettingConnection with possible values: unknown,yes,no. The value indicates the presence of limitations in the amount of traffic flowing through the connection.
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
libnm-core: add 'metered' property to NMSettingConnection Add a 'metered' enum property to NMSettingConnection with possible values: unknown,yes,no. The value indicates the presence of limitations in the amount of traffic flowing through the connection.
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;
}
libnm: add 'lldp' property to NMSettingConnection Add the 'lldp' property to NMSettingConnection, which specifies whether the reception and parsing of LLDP frames to discover neighbor devices should be enabled.
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;
}
libnm: backport symbols for metered connections support to 1.0.6 Backport to 1.0.6 the following symbols: - nm_device_get_metered - nm_metered_get_type - nm_setting_connection_get_metered
2015-07-21 19:02:12 +02:00
mdns: add new connection property. Add support for mDNS as a connection-level property. Update ifcfg-rh and keyfile plugins to support it.
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;
}
libnm-core: add connection.llmnr property
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;
}
libnm-core: Add connection.dns-over-tls property
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;
}
all: add NMMptcpFlags and connection.mptcp-flags property
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.
*
libnm: actually export a lot of routines that were supposed to be public Add them to @libnm_1_40_4 as opposed to @libnm_1_42_0 because we now know this is going to be backported to 1.40.4 first.
2022-11-07 20:29:12 +01:00
* Since: 1.42
all: add NMMptcpFlags and connection.mptcp-flags property
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;
}
libnm-core: normalize NMSettingConnection:type property nm_connection_normalize() can now detect the 'type' property based on existing base settings. It can also create a (default) base setting. Signed-off-by: Thomas Haller <thaller@redhat.com>
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'"),
libnm-core: normalize NMSettingConnection:type property nm_connection_normalize() can now detect the 'type' property based on existing base settings. It can also create a (default) base setting. Signed-off-by: Thomas Haller <thaller@redhat.com>
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);
libnm-core: normalize NMSettingConnection:type property nm_connection_normalize() can now detect the 'type' property based on existing base settings. It can also create a (default) base setting. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-08 18:36:02 +02:00
}
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
libnm: move detection/normalization of "connection.slave-type" to a separate function We allow normalizing the slave-type, but sometimes, we may want to validate a profile according to the set slave-type. For example, a "ovs-external-ids" setting should only be allowed for "connection.slave-type=ovs-interface". But during verify, the slave-type may be missing and not yet normalized. We need to be able to obtain the actually used slave-type.
2020-12-09 10:41:05 +01:00
gboolean
_nm_connection_detect_slave_type_full(NMSettingConnection *s_con,
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
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)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
libnm: move detection/normalization of "connection.slave-type" to a separate function We allow normalizing the slave-type, but sometimes, we may want to validate a profile according to the set slave-type. For example, a "ovs-external-ids" setting should only be allowed for "connection.slave-type=ovs-interface". But during verify, the slave-type may be missing and not yet normalized. We need to be able to obtain the actually used slave-type.
2020-12-09 10:41:05 +01:00
NMSettingConnectionPrivate *priv = NM_SETTING_CONNECTION_GET_PRIVATE(s_con);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
gboolean is_slave;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
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;
libnm: move detection/normalization of "connection.slave-type" to a separate function We allow normalizing the slave-type, but sometimes, we may want to validate a profile according to the set slave-type. For example, a "ovs-external-ids" setting should only be allowed for "connection.slave-type=ovs-interface". But during verify, the slave-type may be missing and not yet normalized. We need to be able to obtain the actually used slave-type.
2020-12-09 10:41:05 +01:00
is_slave = FALSE;
slave_setting_type = NULL;
connection: deprecate the NMSettingConnection slave-type property To embrace inclusive language, deprecate the NMSettingConnection slave-type property and introduce port-type property. Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
2024-01-16 13:58:11 +01:00
slave_type = priv->port_type;
libnm: move detection/normalization of "connection.slave-type" to a separate function We allow normalizing the slave-type, but sometimes, we may want to validate a profile according to the set slave-type. For example, a "ovs-external-ids" setting should only be allowed for "connection.slave-type=ovs-interface". But during verify, the slave-type may be missing and not yet normalized. We need to be able to obtain the actually used slave-type.
2020-12-09 10:41:05 +01:00
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) {
connection: deprecate the NMSettingConnection Master property To embrace inclusive language, deprecate the NMSettingConnection Master property and introduce Controller property.
2023-11-29 14:43:43 +01:00
if (!priv->controller) {
libnm: move detection/normalization of "connection.slave-type" to a separate function We allow normalizing the slave-type, but sometimes, we may want to validate a profile according to the set slave-type. For example, a "ovs-external-ids" setting should only be allowed for "connection.slave-type=ovs-interface". But during verify, the slave-type may be missing and not yet normalized. We need to be able to obtain the actually used slave-type.
2020-12-09 10:41:05 +01:00
g_set_error(error,
NM_CONNECTION_ERROR,
NM_CONNECTION_ERROR_MISSING_PROPERTY,
_("Slave connections need a valid '%s' property"),
all: use the new NMSettingConnection Controller property
2023-11-29 15:24:50 +01:00
NM_SETTING_CONNECTION_CONTROLLER);
libnm: move detection/normalization of "connection.slave-type" to a separate function We allow normalizing the slave-type, but sometimes, we may want to validate a profile according to the set slave-type. For example, a "ovs-external-ids" setting should only be allowed for "connection.slave-type=ovs-interface". But during verify, the slave-type may be missing and not yet normalized. We need to be able to obtain the actually used slave-type.
2020-12-09 10:41:05 +01:00
g_prefix_error(error,
"%s.%s: ",
NM_SETTING_CONNECTION_SETTING_NAME,
all: use the new NMSettingConnection Controller property
2023-11-29 15:24:50 +01:00
NM_SETTING_CONNECTION_CONTROLLER);
libnm: move detection/normalization of "connection.slave-type" to a separate function We allow normalizing the slave-type, but sometimes, we may want to validate a profile according to the set slave-type. For example, a "ovs-external-ids" setting should only be allowed for "connection.slave-type=ovs-interface". But during verify, the slave-type may be missing and not yet normalized. We need to be able to obtain the actually used slave-type.
2020-12-09 10:41:05 +01:00
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);
connection: deprecate the NMSettingConnection Master property To embrace inclusive language, deprecate the NMSettingConnection Master property and introduce Controller property.
2023-11-29 14:43:43 +01:00
if (priv->controller) {
libnm: move detection/normalization of "connection.slave-type" to a separate function We allow normalizing the slave-type, but sometimes, we may want to validate a profile according to the set slave-type. For example, a "ovs-external-ids" setting should only be allowed for "connection.slave-type=ovs-interface". But during verify, the slave-type may be missing and not yet normalized. We need to be able to obtain the actually used slave-type.
2020-12-09 10:41:05 +01:00
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'"),
all: use the new NMSettingConnection Controller property
2023-11-29 15:24:50 +01:00
NM_SETTING_CONNECTION_CONTROLLER,
libnm: move detection/normalization of "connection.slave-type" to a separate function We allow normalizing the slave-type, but sometimes, we may want to validate a profile according to the set slave-type. For example, a "ovs-external-ids" setting should only be allowed for "connection.slave-type=ovs-interface". But during verify, the slave-type may be missing and not yet normalized. We need to be able to obtain the actually used slave-type.
2020-12-09 10:41:05 +01:00
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)
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMSettingConnection *self = NM_SETTING_CONNECTION(setting);
libnm: move detection/normalization of "connection.slave-type" to a separate function We allow normalizing the slave-type, but sometimes, we may want to validate a profile according to the set slave-type. For example, a "ovs-external-ids" setting should only be allowed for "connection.slave-type=ovs-interface". But during verify, the slave-type may be missing and not yet normalized. We need to be able to obtain the actually used slave-type.
2020-12-09 10:41:05 +01:00
NMSettingConnectionPrivate *priv = NM_SETTING_CONNECTION_GET_PRIVATE(self);
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
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;
libnm-core: normalize NMSettingConnection:type property nm_connection_normalize() can now detect the 'type' property based on existing base settings. It can also create a (default) base setting. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-08 18:36:02 +02:00
gboolean normerr_base_setting = FALSE;
libnm: normalize "connection.uuid" For NetworkManager profiles, "connection.uuid" is the identifier of the profile. It is supposed to be a UUID, however: - the UUID was not ensured to be all-lower case. We should make sure that our UUIDs are in a consistent manner, so that users can rely on the format of the string. - the UUID was never actually interpreted as a UUID. It only was some opaque string, that we use as identifier. We had nm_utils_is_uuid() which checks that the format is valid, however that did not fully validate the format, like it would accept "----7daf444dd78741a59e1ef1b3c8b1c0e8" and "549fac10a25f4bcc912d1ae688c2b4987daf444d" (40 hex characters). Both invalid UUIDs and non-normalized UUID should be normalized. We don't want to break existing profiles that use such UUIDs, thus we don't outright reject them. Let's instead mangle them during nm_connection_normalize().
2021-05-02 22:42:51 +02:00
gboolean uuid_was_normalized = FALSE;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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,
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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;
libnm-core: stricter verification of NMSettingConnection:type property Now also verify the 'type' property regardless of existing @all_settings. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-08 17:22:43 +02:00
} else if (!priv->id[0]) {
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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,
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: normalize "connection.uuid" For NetworkManager profiles, "connection.uuid" is the identifier of the profile. It is supposed to be a UUID, however: - the UUID was not ensured to be all-lower case. We should make sure that our UUIDs are in a consistent manner, so that users can rely on the format of the string. - the UUID was never actually interpreted as a UUID. It only was some opaque string, that we use as identifier. We had nm_utils_is_uuid() which checks that the format is valid, however that did not fully validate the format, like it would accept "----7daf444dd78741a59e1ef1b3c8b1c0e8" and "549fac10a25f4bcc912d1ae688c2b4987daf444d" (40 hex characters). Both invalid UUIDs and non-normalized UUID should be normalized. We don't want to break existing profiles that use such UUIDs, thus we don't outright reject them. Let's instead mangle them during nm_connection_normalize().
2021-05-02 22:42:51 +02:00
if (priv->uuid && !nm_uuid_is_valid_nm(priv->uuid, &uuid_was_normalized, NULL)) {
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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,
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: fix normalizing and verifying OVS connections Normalizing can be complicated, as settings depend on each other and possibly conflict. That is, because verify() must exactly anticipate whether normalization will succeed and how the result will look like. That is because we only want to modify the connection, if we are sure that the result will verify. Hence, verify() and normalize() are strongly related. The implementation should not be spread out between NMSettingOvsInterface:verify(), NMSettingOvsPatch:verify() and _normalize_ovs_interface_type(). Also, add some unit-tests.
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))) {
libnm-core: normalize NMSettingConnection:type property nm_connection_normalize() can now detect the 'type' property based on existing base settings. It can also create a (default) base setting. Signed-off-by: Thomas Haller <thaller@redhat.com>
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,
libnm-core: normalize NMSettingConnection:type property nm_connection_normalize() can now detect the 'type' property based on existing base settings. It can also create a (default) base setting. Signed-off-by: Thomas Haller <thaller@redhat.com>
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;
}
libnm: fix normalizing and verifying OVS connections Normalizing can be complicated, as settings depend on each other and possibly conflict. That is, because verify() must exactly anticipate whether normalization will succeed and how the result will look like. That is because we only want to modify the connection, if we are sure that the result will verify. Hence, verify() and normalize() are strongly related. The implementation should not be spread out between NMSettingOvsInterface:verify(), NMSettingOvsPatch:verify() and _normalize_ovs_interface_type(). Also, add some unit-tests.
2017-10-27 14:30:18 +02:00
type = nm_setting_get_name(normerr_base_type);
libnm-core: stricter verification of NMSettingConnection:type property Now also verify the 'type' property regardless of existing @all_settings. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-08 17:22:43 +02:00
} else {
GType base_type;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: fix normalizing and verifying OVS connections Normalizing can be complicated, as settings depend on each other and possibly conflict. That is, because verify() must exactly anticipate whether normalization will succeed and how the result will look like. That is because we only want to modify the connection, if we are sure that the result will verify. Hence, verify() and normalize() are strongly related. The implementation should not be spread out between NMSettingOvsInterface:verify(), NMSettingOvsPatch:verify() and _normalize_ovs_interface_type(). Also, add some unit-tests.
2017-10-27 14:30:18 +02:00
if (!type[0]) {
libnm-core: stricter verification of NMSettingConnection:type property Now also verify the 'type' property regardless of existing @all_settings. Signed-off-by: Thomas Haller <thaller@redhat.com>
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,
libnm-core: stricter verification of NMSettingConnection:type property Now also verify the 'type' property regardless of existing @all_settings. Signed-off-by: Thomas Haller <thaller@redhat.com>
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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: fix normalizing and verifying OVS connections Normalizing can be complicated, as settings depend on each other and possibly conflict. That is, because verify() must exactly anticipate whether normalization will succeed and how the result will look like. That is because we only want to modify the connection, if we are sure that the result will verify. Hence, verify() and normalize() are strongly related. The implementation should not be spread out between NMSettingOvsInterface:verify(), NMSettingOvsPatch:verify() and _normalize_ovs_interface_type(). Also, add some unit-tests.
2017-10-27 14:30:18 +02:00
base_type = nm_setting_lookup_type(type);
libnm: add enum for setting priorities Using plain numbers make it cumbersome to grep for setting types by priority. The only downside is, that with the enum values it is no longer obvious which value has higher or lower priority. Also, introduce NM_SETTING_PRIORITY_INVALID. This is what _nm_setting_type_get_base_type_priority() returns. For the moment it still has the same numerical value 0 as before. Later, that shall be distinct from NM_SETTING_PRIORITY_CONNECTION.
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) {
libnm-core: move validation of NMSettingConnection:type to NMSettingConnection:verify() Partly it was already there. This makes NMSettingConnection:verify() stricter then before, but validates the same as of NMConnection:_nm_connection_verify(). Signed-off-by: Thomas Haller <thaller@redhat.com>
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,
libnm-core: stricter verification of NMSettingConnection:type property Now also verify the 'type' property regardless of existing @all_settings. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-08 17:22:43 +02:00
_("connection type '%s' is not valid"),
libnm: fix normalizing and verifying OVS connections Normalizing can be complicated, as settings depend on each other and possibly conflict. That is, because verify() must exactly anticipate whether normalization will succeed and how the result will look like. That is because we only want to modify the connection, if we are sure that the result will verify. Hence, verify() and normalize() are strongly related. The implementation should not be spread out between NMSettingOvsInterface:verify(), NMSettingOvsPatch:verify() and _normalize_ovs_interface_type(). Also, add some unit-tests.
2017-10-27 14:30:18 +02:00
type);
libnm-core: move validation of NMSettingConnection:type to NMSettingConnection:verify() Partly it was already there. This makes NMSettingConnection:verify() stricter then before, but validates the same as of NMConnection:_nm_connection_verify(). Signed-off-by: Thomas Haller <thaller@redhat.com>
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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm-core: stricter verification of NMSettingConnection:type property Now also verify the 'type' property regardless of existing @all_settings. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-08 17:22:43 +02:00
/* Make sure the corresponding 'type' item is present */
libnm: fix normalizing and verifying OVS connections Normalizing can be complicated, as settings depend on each other and possibly conflict. That is, because verify() must exactly anticipate whether normalization will succeed and how the result will look like. That is because we only want to modify the connection, if we are sure that the result will verify. Hence, verify() and normalize() are strongly related. The implementation should not be spread out between NMSettingOvsInterface:verify(), NMSettingOvsPatch:verify() and _normalize_ovs_interface_type(). Also, add some unit-tests.
2017-10-27 14:30:18 +02:00
if (connection && !nm_connection_get_setting_by_name(connection, type)) {
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMSetting *s_base;
libnm-core: make nm_setting_verify() take an NMConnection nm_setting_verify() took a GSList of other NMSettings, but really it would just be simpler all around to pass the NMConnection instead... This means that several formerly NMSetting-branded functions that operated on lists-of-settings now get replaced with NMConnection-branded functions instead.
2014-10-21 22:30:31 -04:00
NMConnection *connection2;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm-core: normalize NMSettingConnection:type property nm_connection_normalize() can now detect the 'type' property based on existing base settings. It can also create a (default) base setting. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-08 18:36:02 +02:00
s_base = g_object_new(base_type, NULL);
libnm-core: make nm_setting_verify() take an NMConnection nm_setting_verify() took a GSList of other NMSettings, but really it would just be simpler all around to pass the NMConnection instead... This means that several formerly NMSetting-branded functions that operated on lists-of-settings now get replaced with NMConnection-branded functions instead.
2014-10-21 22:30:31 -04:00
connection2 = nm_simple_connection_new_clone(connection);
nm_connection_add_setting(connection2, s_base);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm-core: make nm_setting_verify() take an NMConnection nm_setting_verify() took a GSList of other NMSettings, but really it would just be simpler all around to pass the NMConnection instead... This means that several formerly NMSetting-branded functions that operated on lists-of-settings now get replaced with NMConnection-branded functions instead.
2014-10-21 22:30:31 -04:00
normerr_base_setting = nm_setting_verify(s_base, connection2, NULL);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm-core: make nm_setting_verify() take an NMConnection nm_setting_verify() took a GSList of other NMSettings, but really it would just be simpler all around to pass the NMConnection instead... This means that several formerly NMSetting-branded functions that operated on lists-of-settings now get replaced with NMConnection-branded functions instead.
2014-10-21 22:30:31 -04:00
g_object_unref(connection2);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm-core: normalize NMSettingConnection:type property nm_connection_normalize() can now detect the 'type' property based on existing base settings. It can also create a (default) base setting. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-08 18:36:02 +02:00
if (!normerr_base_setting) {
libnm: fix normalizing and verifying OVS connections Normalizing can be complicated, as settings depend on each other and possibly conflict. That is, because verify() must exactly anticipate whether normalization will succeed and how the result will look like. That is because we only want to modify the connection, if we are sure that the result will verify. Hence, verify() and normalize() are strongly related. The implementation should not be spread out between NMSettingOvsInterface:verify(), NMSettingOvsPatch:verify() and _normalize_ovs_interface_type(). Also, add some unit-tests.
2017-10-27 14:30:18 +02:00
_set_error_missing_base_setting(error, type);
libnm-core: normalize NMSettingConnection:type property nm_connection_normalize() can now detect the 'type' property based on existing base settings. It can also create a (default) base setting. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-08 18:36:02 +02:00
return FALSE;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
}
}
libnm-core: use different ifname validation function for OVS bridges, ports and interfaces OVS bridges and ports do not have the length limitation of 15 bytes, the only requirements are that all chars must be alphanumeric and not be forward or backward slashes. For OVS interfaces only 'patch' types do not have the length limit, all the other types do (according to whether they have a corresponding kernel link or not). Add related unit test. https://bugzilla.redhat.com/show_bug.cgi?id=1788432
2020-02-06 17:17:49 +01:00
if (priv->interface_name) {
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GError *tmp_error = NULL;
libnm: validate "connection.interface-name" at one place only Don't spread the validation for the interface name between multiple places. There should be one place only, so when you search for how this property gets verified, you can find the single place. That requires to move the special handling for OVS interfaces to NMSettingConnection. Since we already have _nm_setting_ovs_interface_verify_interface_type(), that is easy.
2020-02-18 14:00:10 +01:00
NMUtilsIfaceType iface_type;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm-core: use different ifname validation function for OVS bridges, ports and interfaces OVS bridges and ports do not have the length limitation of 15 bytes, the only requirements are that all chars must be alphanumeric and not be forward or backward slashes. For OVS interfaces only 'patch' types do not have the length limit, all the other types do (according to whether they have a corresponding kernel link or not). Add related unit test. https://bugzilla.redhat.com/show_bug.cgi?id=1788432
2020-02-06 17:17:49 +01:00
if (NM_IN_STRSET(type,
NM_SETTING_OVS_BRIDGE_SETTING_NAME,
libnm: validate "connection.interface-name" at one place only Don't spread the validation for the interface name between multiple places. There should be one place only, so when you search for how this property gets verified, you can find the single place. That requires to move the special handling for OVS interfaces to NMSettingConnection. Since we already have _nm_setting_ovs_interface_verify_interface_type(), that is easy.
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;
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const char *ovs_iface_type;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: validate "connection.interface-name" at one place only Don't spread the validation for the interface name between multiple places. There should be one place only, so when you search for how this property gets verified, you can find the single place. That requires to move the special handling for OVS interfaces to NMSettingConnection. Since we already have _nm_setting_ovs_interface_verify_interface_type(), that is easy.
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: validate "connection.interface-name" at one place only Don't spread the validation for the interface name between multiple places. There should be one place only, so when you search for how this property gets verified, you can find the single place. That requires to move the special handling for OVS interfaces to NMSettingConnection. Since we already have _nm_setting_ovs_interface_verify_interface_type(), that is easy.
2020-02-18 14:00:10 +01:00
if (!nm_utils_ifname_valid(priv->interface_name, iface_type, &tmp_error)) {
libnm-core: use different ifname validation function for OVS bridges, ports and interfaces OVS bridges and ports do not have the length limitation of 15 bytes, the only requirements are that all chars must be alphanumeric and not be forward or backward slashes. For OVS interfaces only 'patch' types do not have the length limit, all the other types do (according to whether they have a corresponding kernel link or not). Add related unit test. https://bugzilla.redhat.com/show_bug.cgi?id=1788432
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;
}
}
libnm: validate "connection.interface-name" at one place only Don't spread the validation for the interface name between multiple places. There should be one place only, so when you search for how this property gets verified, you can find the single place. That requires to move the special handling for OVS interfaces to NMSettingConnection. Since we already have _nm_setting_ovs_interface_verify_interface_type(), that is easy.
2020-02-18 14:00:10 +01:00
after_interface_name:
libnm-core: use different ifname validation function for OVS bridges, ports and interfaces OVS bridges and ports do not have the length limitation of 15 bytes, the only requirements are that all chars must be alphanumeric and not be forward or backward slashes. For OVS interfaces only 'patch' types do not have the length limit, all the other types do (according to whether they have a corresponding kernel link or not). Add related unit test. https://bugzilla.redhat.com/show_bug.cgi?id=1788432
2020-02-06 17:17:49 +01:00
libnm: move detection/normalization of "connection.slave-type" to a separate function We allow normalizing the slave-type, but sometimes, we may want to validate a profile according to the set slave-type. For example, a "ovs-external-ids" setting should only be allowed for "connection.slave-type=ovs-interface". But during verify, the slave-type may be missing and not yet normalized. We need to be able to obtain the actually used slave-type.
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;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: move detection/normalization of "connection.slave-type" to a separate function We allow normalizing the slave-type, but sometimes, we may want to validate a profile according to the set slave-type. For example, a "ovs-external-ids" setting should only be allowed for "connection.slave-type=ovs-interface". But during verify, the slave-type may be missing and not yet normalized. We need to be able to obtain the actually used slave-type.
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)) {
libnm-core: add ovs-bridge setting
2017-08-01 18:36:34 +02:00
g_set_error(error,
NM_CONNECTION_ERROR,
NM_CONNECTION_ERROR_MISSING_PROPERTY,
setting-connection: fix ovs-port parent setting verification $ nmcli c add type ovs-port ifname ovsport0 Error: Failed to add 'ovs-port-ovsport0' connection: connection.type: Only 'ovs-port' connections can be enslaved to 'ovs-bridge' nm_streq0() is not good here. It fails (with a wrong error message) even when the slave_type is not set, which it shouldn't since slave_type can be normalized. The real problem is the lack of the master property. This fixes the condition: $ nmcli c add type ovs-port ifname ovsport0 Error: Failed to add 'ovs-port-ovsport0' connection: connection.master: A connection with a 'ovs-port' setting must have a master. Corrects the error message: $ nmcli c add con-name br0 type bridge $ nmcli c add type ovs-port ifname ovsport0 parent br0 Error: Failed to add 'bridge-slave-ovsport0' connection: connection.slave-type: 'ovs-port' connections must be enslaved to 'ovs-bridge', not 'bridge' And gets rid of a confusing nm_streq0 use when comparing the type, since at that point type must not be NULL anymore. Fixes: 4199c976dac21c22773e0c133c42c3b738ca76d2
2018-07-10 15:09:40 +02:00
_("'%s' connections must be enslaved to '%s', not '%s'"),
libnm-core: add ovs-bridge setting
2017-08-01 18:36:34 +02:00
NM_SETTING_OVS_PORT_SETTING_NAME,
setting-connection: fix ovs-port parent setting verification $ nmcli c add type ovs-port ifname ovsport0 Error: Failed to add 'ovs-port-ovsport0' connection: connection.type: Only 'ovs-port' connections can be enslaved to 'ovs-bridge' nm_streq0() is not good here. It fails (with a wrong error message) even when the slave_type is not set, which it shouldn't since slave_type can be normalized. The real problem is the lack of the master property. This fixes the condition: $ nmcli c add type ovs-port ifname ovsport0 Error: Failed to add 'ovs-port-ovsport0' connection: connection.master: A connection with a 'ovs-port' setting must have a master. Corrects the error message: $ nmcli c add con-name br0 type bridge $ nmcli c add type ovs-port ifname ovsport0 parent br0 Error: Failed to add 'bridge-slave-ovsport0' connection: connection.slave-type: 'ovs-port' connections must be enslaved to 'ovs-bridge', not 'bridge' And gets rid of a confusing nm_streq0 use when comparing the type, since at that point type must not be NULL anymore. Fixes: 4199c976dac21c22773e0c133c42c3b738ca76d2
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);
libnm-core: add ovs-bridge setting
2017-08-01 18:36:34 +02:00
return FALSE;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: refactor some NMSetting to use direct properties "direct" properties are the latest preferred way to implement GObject base properties. That way, the property meta data tracks the "direct_type" and the offset where to find the data in the struct. That way, we can automatically - initialize the default values - free during finalize - implement get_property()/set_property() Also, the other settings operations (compare, to/from D-Bus) are implemented more efficiently and don't need to go through g_object_get_property()/GValue API.
2021-10-20 16:13:14 +02:00
if (!NM_IN_SET(priv->metered, NM_METERED_UNKNOWN, NM_METERED_NO, NM_METERED_YES)) {
libnm-core: add 'metered' property to NMSettingConnection Add a 'metered' enum property to NMSettingConnection with possible values: unknown,yes,no. The value indicates the presence of limitations in the amount of traffic flowing through the connection.
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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm-core: add connection.llmnr property
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) {
libnm: verify value for connection.mdns Also, keep the internal variable of type int. The only way to set the field is via the GObject property setter. At that point, don't yet cast the integer type to enum.
2017-12-15 12:11:53 +01:00
g_set_error(error,
NM_CONNECTION_ERROR,
NM_CONNECTION_ERROR_INVALID_PROPERTY,
libnm-core: add connection.llmnr property
2018-08-31 10:48:18 +02:00
_("value %d is not valid"),
priv->mdns);
libnm: verify value for connection.mdns Also, keep the internal variable of type int. The only way to set the field is via the GObject property setter. At that point, don't yet cast the integer type to enum.
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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm-core: add connection.llmnr property
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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm-core: Add connection.dns-over-tls property
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;
}
all: add NMMptcpFlags and connection.mptcp-flags property
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);
all: add NMMptcpFlags and connection.mptcp-flags property
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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: fix verification of connection:mud-url property For one, the setters sd_dhcp_client_set_mud_url() and sd_dhcp6_client_set_request_mud_url() assert that the value honors these settings. So, we must never pass such values to the function. Also, before calling n_dhcp4_client_probe_config_append_option() the code doesn't check whether the URL is short enough. That would be a bug (unless we ensure that the property is valid from the beginning). In general, it is necessary to strictly validate the parameter. Also, returning NM_SETTING_VERIFY_NORMALIZABLE_ERROR for a property that does not get normalized is a bug.
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;
}
dhcp: make connection.mud-url configurable as global connection default Conceptionally, the MUD URL really depends on the device, and not so much the connection profile. That is, when you have a specific IoT device, then this device probably should use the same MUD URL for all profiles (at least by default). We already have a mechanism for that: global connection defaults. Use that. This allows a vendor drop pre-install a file "/usr/lib/NetworkManager/conf.d/10-mud-url.conf" with [connection-10-mud-url] connection.mud-url=https://example.com Note that we introduce the special "connection.mud-url" value "none", to indicate not to use a MUD URL (but also not to consult the global connection default).
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;
}
libnm: fix verification of connection:mud-url property For one, the setters sd_dhcp_client_set_mud_url() and sd_dhcp6_client_set_request_mud_url() assert that the value honors these settings. So, we must never pass such values to the function. Also, before calling n_dhcp4_client_probe_config_append_option() the code doesn't check whether the URL is short enough. That would be a bug (unless we ensure that the property is valid from the beginning). In general, it is necessary to strictly validate the parameter. Also, returning NM_SETTING_VERIFY_NORMALIZABLE_ERROR for a property that does not get normalized is a bug.
2020-04-24 09:31:30 +02:00
}
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
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++) {
all: use nm_g_array_{index,first,last,index_p}() instead of g_array_index() These variants provide additional nm_assert() checks, and are thus preferable. Note that we cannot just blindly replace &g_array_index() with &nm_g_array_index(), because the latter would not allow getting a pointer at index [arr->len]. That might be a valid (though uncommon) usecase. The correct replacement of &g_array_index() is thus nm_g_array_index_p(). I checked the code manually and replaced uses of nm_g_array_index_p() with &nm_g_array_index(), if that was a safe thing to do. The latter seems preferable, because it is familar to &g_array_index().
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));
}
}
libnm-core: normalize slave-type and slave-settings of connections Some NMSettingConnection:slave-type types require a matching slave #NMSetting. Add normalization of either the 'slave-type' property or the slave-setting. Also be more strict in NMSettingConnection:verify() to enforce an existing slave-setting depending on the slave-type. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-07 17:05:10 +02:00
/* *** errors above here should be always fatal, below NORMALIZABLE_ERROR *** */
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: normalize missing connection UUID Extend nm_connection_normalize() to add a connection UUID in case it is unset.
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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm-core: normalize NMSettingConnection:type property nm_connection_normalize() can now detect the 'type' property based on existing base settings. It can also create a (default) base setting. Signed-off-by: Thomas Haller <thaller@redhat.com>
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,
libnm-core: normalize NMSettingConnection:type property nm_connection_normalize() can now detect the 'type' property based on existing base settings. It can also create a (default) base setting. Signed-off-by: Thomas Haller <thaller@redhat.com>
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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm-core: normalize NMSettingConnection:type property nm_connection_normalize() can now detect the 'type' property based on existing base settings. It can also create a (default) base setting. Signed-off-by: Thomas Haller <thaller@redhat.com>
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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm-core: normalize slave-type and slave-settings of connections Some NMSettingConnection:slave-type types require a matching slave #NMSetting. Add normalization of either the 'slave-type' property or the slave-setting. Also be more strict in NMSettingConnection:verify() to enforce an existing slave-setting depending on the slave-type. Signed-off-by: Thomas Haller <thaller@redhat.com>
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,
connection: deprecate the NMSettingConnection slave-type property To embrace inclusive language, deprecate the NMSettingConnection slave-type property and introduce port-type property. Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
2024-01-16 13:58:11 +01:00
_("port-type '%s' requires a '%s' setting in the connection"),
priv->port_type,
libnm-core: normalize slave-type and slave-settings of connections Some NMSettingConnection:slave-type types require a matching slave #NMSetting. Add normalization of either the 'slave-type' property or the slave-setting. Also be more strict in NMSettingConnection:verify() to enforce an existing slave-setting depending on the slave-type. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-07 17:05:10 +02:00
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);
libnm-core: normalize slave-type and slave-settings of connections Some NMSettingConnection:slave-type types require a matching slave #NMSetting. Add normalization of either the 'slave-type' property or the slave-setting. Also be more strict in NMSettingConnection:verify() to enforce an existing slave-setting depending on the slave-type. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-07-07 17:05:10 +02:00
return NM_SETTING_VERIFY_NORMALIZABLE_ERROR;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm-core: normalize slave-type and slave-settings of connections Some NMSettingConnection:slave-type types require a matching slave #NMSetting. Add normalization of either the 'slave-type' property or the slave-setting. Also be more strict in NMSettingConnection:verify() to enforce an existing slave-setting depending on the slave-type. Signed-off-by: Thomas Haller <thaller@redhat.com>
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,
translations: avoid preprocessor strings inside translation macro https://bugzilla.gnome.org/show_bug.cgi?id=740381 Reported-by: Yuri Chornoivan <yurchor@ukr.net>
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'"),
all: use the new NMSettingConnection Controller property
2023-11-29 15:24:50 +01:00
NM_SETTING_CONNECTION_CONTROLLER,
translations: avoid preprocessor strings inside translation macro https://bugzilla.gnome.org/show_bug.cgi?id=740381 Reported-by: Yuri Chornoivan <yurchor@ukr.net>
2014-11-20 12:33:49 +01:00
normerr_missing_slave_type_port,
NM_SETTING_CONNECTION_SLAVE_TYPE,
normerr_missing_slave_type);
libnm-core: normalize slave-type and slave-settings of connections Some NMSettingConnection:slave-type types require a matching slave #NMSetting. Add normalization of either the 'slave-type' property or the slave-setting. Also be more strict in NMSettingConnection:verify() to enforce an existing slave-setting depending on the slave-type. Signed-off-by: Thomas Haller <thaller@redhat.com>
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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm-core: normalize invalid bridge|team slave-port settings Having a bridge-port/team-port setting for a connection that has a different slave-type makes no sense. Such a configuration shall be considered invalid, and be fixed by normalization. Note that there is already a normalization the other way around, when you omit the "slave-type" but a "master" and one(!) port-type setting is present, the slave-type is automatically determined based on the port-type. The use of this is of course to modify an existing slave connection to make it a non-slave. Then the invalid port settings should be automatically removed. Previously, ifcfg-rh writer would write the "BRIDGING_OPTS" setting without a "BRIDGE". The reader would then (correctly) ignore the bridge-port. Avoid that altogehter, by requiring the connection to strictly verify.
2017-03-01 13:50:59 +01:00
if (connection) {
gboolean has_bridge_port = FALSE;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
connection: deprecate the NMSettingConnection slave-type property To embrace inclusive language, deprecate the NMSettingConnection slave-type property and introduce port-type property. Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
2024-01-16 13:58:11 +01:00
if ((!nm_streq0(priv->port_type, NM_SETTING_BRIDGE_SETTING_NAME)
libnm-core: normalize invalid bridge|team slave-port settings Having a bridge-port/team-port setting for a connection that has a different slave-type makes no sense. Such a configuration shall be considered invalid, and be fixed by normalization. Note that there is already a normalization the other way around, when you omit the "slave-type" but a "master" and one(!) port-type setting is present, the slave-type is automatically determined based on the port-type. The use of this is of course to modify an existing slave connection to make it a non-slave. Then the invalid port settings should be automatically removed. Previously, ifcfg-rh writer would write the "BRIDGING_OPTS" setting without a "BRIDGE". The reader would then (correctly) ignore the bridge-port. Avoid that altogehter, by requiring the connection to strictly verify.
2017-03-01 13:50:59 +01:00
&& (has_bridge_port =
!!nm_connection_get_setting_by_name(connection,
NM_SETTING_BRIDGE_PORT_SETTING_NAME)))
connection: deprecate the NMSettingConnection slave-type property To embrace inclusive language, deprecate the NMSettingConnection slave-type property and introduce port-type property. Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
2024-01-16 13:58:11 +01:00
|| (!nm_streq0(priv->port_type, NM_SETTING_TEAM_SETTING_NAME)
libnm-core: normalize invalid bridge|team slave-port settings Having a bridge-port/team-port setting for a connection that has a different slave-type makes no sense. Such a configuration shall be considered invalid, and be fixed by normalization. Note that there is already a normalization the other way around, when you omit the "slave-type" but a "master" and one(!) port-type setting is present, the slave-type is automatically determined based on the port-type. The use of this is of course to modify an existing slave connection to make it a non-slave. Then the invalid port settings should be automatically removed. Previously, ifcfg-rh writer would write the "BRIDGING_OPTS" setting without a "BRIDGE". The reader would then (correctly) ignore the bridge-port. Avoid that altogehter, by requiring the connection to strictly verify.
2017-03-01 13:50:59 +01:00
&& 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,
connection: deprecate the NMSettingConnection slave-type property To embrace inclusive language, deprecate the NMSettingConnection slave-type property and introduce port-type property. Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
2024-01-16 13:58:11 +01:00
priv->port_type ?: "",
libnm-core: normalize invalid bridge|team slave-port settings Having a bridge-port/team-port setting for a connection that has a different slave-type makes no sense. Such a configuration shall be considered invalid, and be fixed by normalization. Note that there is already a normalization the other way around, when you omit the "slave-type" but a "master" and one(!) port-type setting is present, the slave-type is automatically determined based on the port-type. The use of this is of course to modify an existing slave connection to make it a non-slave. Then the invalid port settings should be automatically removed. Previously, ifcfg-rh writer would write the "BRIDGING_OPTS" setting without a "BRIDGE". The reader would then (correctly) ignore the bridge-port. Avoid that altogehter, by requiring the connection to strictly verify.
2017-03-01 13:50:59 +01:00
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;
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
}
libnm: normalize "connection.uuid" For NetworkManager profiles, "connection.uuid" is the identifier of the profile. It is supposed to be a UUID, however: - the UUID was not ensured to be all-lower case. We should make sure that our UUIDs are in a consistent manner, so that users can rely on the format of the string. - the UUID was never actually interpreted as a UUID. It only was some opaque string, that we use as identifier. We had nm_utils_is_uuid() which checks that the format is valid, however that did not fully validate the format, like it would accept "----7daf444dd78741a59e1ef1b3c8b1c0e8" and "549fac10a25f4bcc912d1ae688c2b4987daf444d" (40 hex characters). Both invalid UUIDs and non-normalized UUID should be normalized. We don't want to break existing profiles that use such UUIDs, thus we don't outright reject them. Let's instead mangle them during nm_connection_normalize().
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;
}
libnm: rework strv properties of NMSetting as "direct" properties Make use of direct strv property in some cases. It doesn't work for other cases yet, because they are implemented differently, and porting them is more effort and needs to be done one by one. The goal is to have a unified, standard implementation for our properties. One that requires a minimal amount of property-specific code. For strv properties, that is a bit more cumbersome, because usually there are multiple C accessor functions. Still, make an effort to have a "direct" strv property. What this also gives, is that we no longer need to clone the strv array for various operations. We know how to access the data, and can do it directly without g_object_get()/g_object_set().
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;
libnm: normalize "connection.read-only" to FALSE
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;
}
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
return TRUE;
}
libnm-core: drop the ability to verify settings from property overrides It needs to be possible to deserialize a connection hash into an invalid NMConnection; in particular, AddAndActivateConnection() explicitly allows this. Previously, the SetFunc and NotSetFunc passed to _nm_setting_class_override_property() could return a verification error immediately, but this functionality has to go away if we're going to be able to deserialize invalid connections. That functionality was only used in the handling of invalid virtual interface names; reorganize how that code works so that NMSettingConnection does all of the verification itself. (The code to make sure that it returned the "correct" error domain in that case turned out to be irrelevant, since the setting error domains don't get serialized over D-Bus correctly anyway.)
2014-09-15 13:30:07 -04:00
static const char *
libnm: in find_virtual_interface_name() ensure return value stays alive It's not clear that the returned string is still valid after we unref the GVariant that contains it. Also return the reference to the variant.
2020-02-17 16:29:25 +01:00
find_virtual_interface_name(GVariant *connection_dict, GVariant **variant_to_free)
libnm-core: drop :interface-name properties on virtual NMSetting types Remove the virtual :interface-name properties and their getters, and use property overrides to do backward-compat handling when serializing/deserializing. Now when constructing an NMConnection from a hash, if the virtual property is set and the NMSettingConnection property isn't, then the override for NMSettingConnection:interface-name will set that property to the value of the virtual interface-name. And when converting an NMConnection to a hash, the overrides for the virtual properties will return the value of NMSettingConnection:interface-name.
2014-08-04 19:57:20 -04:00
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
GVariant *setting_dict;
libnm-core: change connection hash tables to variants in API In preparation for porting to GDBus, make nm_connection_to_dbus(), etc, represent connections as GVariants of type 'a{sa{sv}}' rather than as GHashTables-of-GHashTables-of-GValues. This means we're constantly converting back and forth internally, but this is just a stepping stone on the way to the full GDBus port, and all of that code will go away again later.
2014-08-16 10:09:48 -04:00
const char *interface_name;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: in find_virtual_interface_name() ensure return value stays alive It's not clear that the returned string is still valid after we unref the GVariant that contains it. Also return the reference to the variant.
2020-02-17 16:29:25 +01:00
nm_assert(variant_to_free && !*variant_to_free);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm-core: change connection hash tables to variants in API In preparation for porting to GDBus, make nm_connection_to_dbus(), etc, represent connections as GVariants of type 'a{sa{sv}}' rather than as GHashTables-of-GHashTables-of-GValues. This means we're constantly converting back and forth internally, but this is just a stepping stone on the way to the full GDBus port, and all of that code will go away again later.
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm-core: change connection hash tables to variants in API In preparation for porting to GDBus, make nm_connection_to_dbus(), etc, represent connections as GVariants of type 'a{sa{sv}}' rather than as GHashTables-of-GHashTables-of-GValues. This means we're constantly converting back and forth internally, but this is just a stepping stone on the way to the full GDBus port, and all of that code will go away again later.
2014-08-16 10:09:48 -04:00
if (!setting_dict)
libnm-core: drop the ability to verify settings from property overrides It needs to be possible to deserialize a connection hash into an invalid NMConnection; in particular, AddAndActivateConnection() explicitly allows this. Previously, the SetFunc and NotSetFunc passed to _nm_setting_class_override_property() could return a verification error immediately, but this functionality has to go away if we're going to be able to deserialize invalid connections. That functionality was only used in the handling of invalid virtual interface names; reorganize how that code works so that NMSettingConnection does all of the verification itself. (The code to make sure that it returned the "correct" error domain in that case turned out to be irrelevant, since the setting error domains don't get serialized over D-Bus correctly anyway.)
2014-09-15 13:30:07 -04:00
return NULL;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: in find_virtual_interface_name() ensure return value stays alive It's not clear that the returned string is still valid after we unref the GVariant that contains it. Also return the reference to the variant.
2020-02-17 16:29:25 +01:00
*variant_to_free = setting_dict;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm-core: drop :interface-name properties on virtual NMSetting types Remove the virtual :interface-name properties and their getters, and use property overrides to do backward-compat handling when serializing/deserializing. Now when constructing an NMConnection from a hash, if the virtual property is set and the NMSettingConnection property isn't, then the override for NMSettingConnection:interface-name will set that property to the value of the virtual interface-name. And when converting an NMConnection to a hash, the overrides for the virtual properties will return the value of NMSettingConnection:interface-name.
2014-08-04 19:57:20 -04:00
/* All of the deprecated virtual interface name properties were named "interface-name". */
libnm-core: change connection hash tables to variants in API In preparation for porting to GDBus, make nm_connection_to_dbus(), etc, represent connections as GVariants of type 'a{sa{sv}}' rather than as GHashTables-of-GHashTables-of-GValues. This means we're constantly converting back and forth internally, but this is just a stepping stone on the way to the full GDBus port, and all of that code will go away again later.
2014-08-16 10:09:48 -04:00
if (!g_variant_lookup(setting_dict, "interface-name", "&s", &interface_name))
libnm: fix memleak in find_virtual_interface_name()
2015-02-06 16:36:55 +01:00
interface_name = NULL;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm-core: change connection hash tables to variants in API In preparation for porting to GDBus, make nm_connection_to_dbus(), etc, represent connections as GVariants of type 'a{sa{sv}}' rather than as GHashTables-of-GHashTables-of-GValues. This means we're constantly converting back and forth internally, but this is just a stepping stone on the way to the full GDBus port, and all of that code will go away again later.
2014-08-16 10:09:48 -04:00
return interface_name;
libnm-core: drop the ability to verify settings from property overrides It needs to be possible to deserialize a connection hash into an invalid NMConnection; in particular, AddAndActivateConnection() explicitly allows this. Previously, the SetFunc and NotSetFunc passed to _nm_setting_class_override_property() could return a verification error immediately, but this functionality has to go away if we're going to be able to deserialize invalid connections. That functionality was only used in the handling of invalid virtual interface names; reorganize how that code works so that NMSettingConnection does all of the verification itself. (The code to make sure that it returned the "correct" error domain in that case turned out to be irrelevant, since the setting error domains don't get serialized over D-Bus correctly anyway.)
2014-09-15 13:30:07 -04:00
}
libnm-core: drop :interface-name properties on virtual NMSetting types Remove the virtual :interface-name properties and their getters, and use property overrides to do backward-compat handling when serializing/deserializing. Now when constructing an NMConnection from a hash, if the virtual property is set and the NMSettingConnection property isn't, then the override for NMSettingConnection:interface-name will set that property to the value of the virtual interface-name. And when converting an NMConnection to a hash, the overrides for the virtual properties will return the value of NMSettingConnection:interface-name.
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)
libnm-core: drop the ability to verify settings from property overrides It needs to be possible to deserialize a connection hash into an invalid NMConnection; in particular, AddAndActivateConnection() explicitly allows this. Previously, the SetFunc and NotSetFunc passed to _nm_setting_class_override_property() could return a verification error immediately, but this functionality has to go away if we're going to be able to deserialize invalid connections. That functionality was only used in the handling of invalid virtual interface names; reorganize how that code works so that NMSettingConnection does all of the verification itself. (The code to make sure that it returned the "correct" error domain in that case turned out to be irrelevant, since the setting error domains don't get serialized over D-Bus correctly anyway.)
2014-09-15 13:30:07 -04:00
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
const char *virtual_interface_name;
libnm: in find_virtual_interface_name() ensure return value stays alive It's not clear that the returned string is still valid after we unref the GVariant that contains it. Also return the reference to the variant.
2020-02-17 16:29:25 +01:00
gs_unref_variant GVariant *variant_to_free = NULL;
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: in find_virtual_interface_name() ensure return value stays alive It's not clear that the returned string is still valid after we unref the GVariant that contains it. Also return the reference to the variant.
2020-02-17 16:29:25 +01:00
virtual_interface_name = find_virtual_interface_name(connection_dict, &variant_to_free);
libnm-core: drop the ability to verify settings from property overrides It needs to be possible to deserialize a connection hash into an invalid NMConnection; in particular, AddAndActivateConnection() explicitly allows this. Previously, the SetFunc and NotSetFunc passed to _nm_setting_class_override_property() could return a verification error immediately, but this functionality has to go away if we're going to be able to deserialize invalid connections. That functionality was only used in the handling of invalid virtual interface names; reorganize how that code works so that NMSettingConnection does all of the verification itself. (The code to make sure that it returned the "correct" error domain in that case turned out to be irrelevant, since the setting error domains don't get serialized over D-Bus correctly anyway.)
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;
libnm-core: drop :interface-name properties on virtual NMSetting types Remove the virtual :interface-name properties and their getters, and use property overrides to do backward-compat handling when serializing/deserializing. Now when constructing an NMConnection from a hash, if the virtual property is set and the NMSettingConnection property isn't, then the override for NMSettingConnection:interface-name will set that property to the value of the virtual interface-name. And when converting an NMConnection to a hash, the overrides for the virtual properties will return the value of NMSettingConnection:interface-name.
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)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
libnm: refactor NMSettingClass.compare_property() to NMSettInfoPropertType.compare_fcn() NMSettingClass.compare_property() will be dropped.
2021-06-29 14:37:16 +02:00
if (NM_FLAGS_HAS(flags, NM_SETTING_COMPARE_FLAG_IGNORE_ID))
return NM_TERNARY_DEFAULT;
libnm: implement "direct" properties for compare_fcn()
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);
libnm: refactor NMSettingClass.compare_property() to NMSettInfoPropertType.compare_fcn() NMSettingClass.compare_property() will be dropped.
2021-06-29 14:37:16 +02:00
}
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: refactor NMSettingClass.compare_property() to NMSettInfoPropertType.compare_fcn() NMSettingClass.compare_property() will be dropped.
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)
libnm: refactor NMSettingClass.compare_property() to NMSettInfoPropertType.compare_fcn() NMSettingClass.compare_property() will be dropped.
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);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
libnm-core: reorder code in settings Order the code in our common way. No other changes. - ensure to include the main header first (directly after "nm-default.h"). - reorder function definitions: get_property(), set_property(), *_init(), *_new(), finalize(), *_class_init().
2019-01-11 08:32:54 +01:00
/*****************************************************************************/
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
static void
libnm-core: reorder code in settings Order the code in our common way. No other changes. - ensure to include the main header first (directly after "nm-default.h"). - reorder function definitions: get_property(), set_property(), *_init(), *_new(), finalize(), *_class_init().
2019-01-11 08:32:54 +01:00
get_property(GObject *object, guint prop_id, GValue *value, GParamSpec *pspec)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
2021-11-09 13:28:54 +01:00
NMSettingConnection *setting = NM_SETTING_CONNECTION(object);
libnm-core: reorder code in settings Order the code in our common way. No other changes. - ensure to include the main header first (directly after "nm-default.h"). - reorder function definitions: get_property(), set_property(), *_init(), *_new(), finalize(), *_class_init().
2019-01-11 08:32:54 +01:00
NMSettingConnectionPrivate *priv = NM_SETTING_CONNECTION_GET_PRIVATE(setting);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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++)
all: use nm_g_array_{index,first,last,index_p}() instead of g_array_index() These variants provide additional nm_assert() checks, and are thus preferable. Note that we cannot just blindly replace &g_array_index() with &nm_g_array_index(), because the latter would not allow getting a pointer at index [arr->len]. That might be a valid (though uncommon) usecase. The correct replacement of &g_array_index() is thus nm_g_array_index_p(). I checked the code manually and replaced uses of nm_g_array_index_p() with &nm_g_array_index(), if that was a safe thing to do. The latter seems preferable, because it is familar to &g_array_index().
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);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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
}
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
case PROP_TIMESTAMP:
libnm-core: reorder code in settings Order the code in our common way. No other changes. - ensure to include the main header first (directly after "nm-default.h"). - reorder function definitions: get_property(), set_property(), *_init(), *_new(), finalize(), *_class_init().
2019-01-11 08:32:54 +01:00
g_value_set_uint64(value, nm_setting_connection_get_timestamp(setting));
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
break;
default:
libnm: refactor some NMSetting to use direct properties "direct" properties are the latest preferred way to implement GObject base properties. That way, the property meta data tracks the "direct_type" and the offset where to find the data in the struct. That way, we can automatically - initialize the default values - free during finalize - implement get_property()/set_property() Also, the other settings operations (compare, to/from D-Bus) are implemented more efficiently and don't need to go through g_object_get_property()/GValue API.
2021-10-20 16:13:14 +02:00
_nm_setting_property_get_property_direct(object, prop_id, value, pspec);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
break;
}
}
static void
libnm-core: reorder code in settings Order the code in our common way. No other changes. - ensure to include the main header first (directly after "nm-default.h"). - reorder function definitions: get_property(), set_property(), *_init(), *_new(), finalize(), *_class_init().
2019-01-11 08:32:54 +01:00
set_property(GObject *object, guint prop_id, const GValue *value, GParamSpec *pspec)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
libnm-core: reorder code in settings Order the code in our common way. No other changes. - ensure to include the main header first (directly after "nm-default.h"). - reorder function definitions: get_property(), set_property(), *_init(), *_new(), finalize(), *_class_init().
2019-01-11 08:32:54 +01:00
NMSettingConnectionPrivate *priv = NM_SETTING_CONNECTION_GET_PRIVATE(object);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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]);
}
}
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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
}
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
case PROP_TIMESTAMP:
libnm-core: reorder code in settings Order the code in our common way. No other changes. - ensure to include the main header first (directly after "nm-default.h"). - reorder function definitions: get_property(), set_property(), *_init(), *_new(), finalize(), *_class_init().
2019-01-11 08:32:54 +01:00
priv->timestamp = g_value_get_uint64(value);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
break;
default:
libnm: refactor some NMSetting to use direct properties "direct" properties are the latest preferred way to implement GObject base properties. That way, the property meta data tracks the "direct_type" and the offset where to find the data in the struct. That way, we can automatically - initialize the default values - free during finalize - implement get_property()/set_property() Also, the other settings operations (compare, to/from D-Bus) are implemented more efficiently and don't need to go through g_object_get_property()/GValue API.
2021-10-20 16:13:14 +02:00
_nm_setting_property_set_property_direct(object, prop_id, value, pspec);
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
break;
}
}
libnm-core: reorder code in settings Order the code in our common way. No other changes. - ensure to include the main header first (directly after "nm-default.h"). - reorder function definitions: get_property(), set_property(), *_init(), *_new(), finalize(), *_class_init().
2019-01-11 08:32:54 +01:00
/*****************************************************************************/
connection: deprecate the NMSettingConnection Master property To embrace inclusive language, deprecate the NMSettingConnection Master property and introduce Controller property.
2023-11-29 14:43:43 +01:00
gboolean
_nm_setting_connection_master_from_dbus(_NM_SETT_INFO_PROP_FROM_DBUS_FCN_ARGS _nm_nil)
{
const char *str;
if (!_nm_setting_use_legacy_property(setting,
connection_dict,
NM_SETTING_CONNECTION_MASTER,
NM_SETTING_CONNECTION_CONTROLLER)) {
*out_is_modified = FALSE;
return TRUE;
}
str = g_variant_get_string(value, NULL);
g_object_set(setting, NM_SETTING_CONNECTION_MASTER, str, NULL);
return TRUE;
}
GVariant *
_nm_setting_connection_controller_to_dbus(_NM_SETT_INFO_PROP_TO_DBUS_FCN_ARGS _nm_nil)
{
const char *controller;
/* FIXME: `controller` is an alias of `master` property. Serializing the
* property to the clients would break them as they won't be able to drop
* it if they are not aware of the existance of `controller`. In order to
* give them time to adapt their code, NetworkManager is not serializing
* `controller` on DBus.
*/
if (_nm_utils_is_manager_process) {
return NULL;
}
controller = nm_setting_connection_get_controller(NM_SETTING_CONNECTION(setting));
if (!controller)
return NULL;
return g_variant_new_string(controller);
}
gboolean
_nm_setting_connection_controller_from_dbus(_NM_SETT_INFO_PROP_FROM_DBUS_FCN_ARGS _nm_nil)
{
const char *str;
/* Ignore 'controller' if we're going to process 'master' */
if (_nm_setting_use_legacy_property(setting,
connection_dict,
NM_SETTING_CONNECTION_MASTER,
NM_SETTING_CONNECTION_CONTROLLER)) {
*out_is_modified = FALSE;
return TRUE;
}
str = g_variant_get_string(value, NULL);
g_object_set(setting, NM_SETTING_CONNECTION_CONTROLLER, str, NULL);
return TRUE;
}
connection: deprecate the NMSettingConnection slave-type property To embrace inclusive language, deprecate the NMSettingConnection slave-type property and introduce port-type property. Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
2024-01-16 13:58:11 +01:00
gboolean
_nm_setting_connection_slave_type_from_dbus(_NM_SETT_INFO_PROP_FROM_DBUS_FCN_ARGS _nm_nil)
{
const char *str;
if (!_nm_setting_use_legacy_property(setting,
connection_dict,
NM_SETTING_CONNECTION_SLAVE_TYPE,
NM_SETTING_CONNECTION_PORT_TYPE)) {
*out_is_modified = FALSE;
return TRUE;
}
str = g_variant_get_string(value, NULL);
g_object_set(setting, NM_SETTING_CONNECTION_SLAVE_TYPE, str, NULL);
return TRUE;
}
GVariant *
_nm_setting_connection_port_type_to_dbus(_NM_SETT_INFO_PROP_TO_DBUS_FCN_ARGS _nm_nil)
{
const char *port_type;
/* FIXME: `port-type` is an alias of `slave-type` property. Serializing the
* property to the clients would break them as they won't be able to drop
* it if they are not aware of the existance of `port-type`. In order to
* give them time to adapt their code, NetworkManager is not serializing
* `port-type` on DBus.
*/
if (_nm_utils_is_manager_process) {
return NULL;
}
port_type = nm_setting_connection_get_port_type(NM_SETTING_CONNECTION(setting));
if (!port_type)
return NULL;
return g_variant_new_string(port_type);
}
gboolean
_nm_setting_connection_port_type_from_dbus(_NM_SETT_INFO_PROP_FROM_DBUS_FCN_ARGS _nm_nil)
{
const char *str;
/* Ignore 'port-type' if we're going to process 'slave-type' */
if (_nm_setting_use_legacy_property(setting,
connection_dict,
NM_SETTING_CONNECTION_SLAVE_TYPE,
NM_SETTING_CONNECTION_PORT_TYPE)) {
*out_is_modified = FALSE;
return TRUE;
}
str = g_variant_get_string(value, NULL);
g_object_set(setting, NM_SETTING_CONNECTION_PORT_TYPE, str, NULL);
return TRUE;
}
connection: deprecate the NMSettingConnection Master property To embrace inclusive language, deprecate the NMSettingConnection Master property and introduce Controller property.
2023-11-29 14:43:43 +01:00
/*****************************************************************************/
libnm-core: reorder code in settings Order the code in our common way. No other changes. - ensure to include the main header first (directly after "nm-default.h"). - reorder function definitions: get_property(), set_property(), *_init(), *_new(), finalize(), *_class_init().
2019-01-11 08:32:54 +01:00
static void
nm_setting_connection_init(NMSettingConnection *setting)
libnm: refactor some NMSetting to use direct properties "direct" properties are the latest preferred way to implement GObject base properties. That way, the property meta data tracks the "direct_type" and the offset where to find the data in the struct. That way, we can automatically - initialize the default values - free during finalize - implement get_property()/set_property() Also, the other settings operations (compare, to/from D-Bus) are implemented more efficiently and don't need to go through g_object_get_property()/GValue API.
2021-10-20 16:13:14 +02:00
{}
libnm-core: reorder code in settings Order the code in our common way. No other changes. - ensure to include the main header first (directly after "nm-default.h"). - reorder function definitions: get_property(), set_property(), *_init(), *_new(), finalize(), *_class_init().
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)
{
all: drop unnecessary cast for return value of g_object_new() C casts unconditionally force the type, and as such they don't necessarily improve type safety, but rather overcome restrictions from the compiler when necessary. Casting a void pointer is unnecessary (in C), it does not make the code more readable nor more safe. In particular for g_object_new(), which is known to return a void pointer of the right type. Drop such casts. sed 's/([A-Za-z_0-9]\+ *\* *) *g_object_new/g_object_new/g' $(git grep -l g_object_new) -i ./contrib/scripts/nm-code-format-container.sh
2020-11-12 15:57:06 +01:00
return g_object_new(NM_TYPE_SETTING_CONNECTION, NULL);
libnm-core: reorder code in settings Order the code in our common way. No other changes. - ensure to include the main header first (directly after "nm-default.h"). - reorder function definitions: get_property(), set_property(), *_init(), *_new(), finalize(), *_class_init().
2019-01-11 08:32:54 +01:00
}
static void
finalize(GObject *object)
{
NMSettingConnectionPrivate *priv = NM_SETTING_CONNECTION_GET_PRIVATE(object);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm-core: reorder code in settings Order the code in our common way. No other changes. - ensure to include the main header first (directly after "nm-default.h"). - reorder function definitions: get_property(), set_property(), *_init(), *_new(), finalize(), *_class_init().
2019-01-11 08:32:54 +01:00
G_OBJECT_CLASS(nm_setting_connection_parent_class)->finalize(object);
}
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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)
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
{
format: reformat source tree with clang-format 13.0 We use clang-format for automatic formatting of our source files. Since clang-format is actively maintained software, the actual formatting depends on the used version of clang-format. That is unfortunate and painful, but really unavoidable unless clang-format would be strictly bug-compatible. So the version that we must use is from the current Fedora release, which is also tested by our gitlab-ci. Previously, we were using Fedora 34 with clang-tools-extra-12.0.1-1.fc34.x86_64. As Fedora 35 comes along, we need to update our formatting as Fedora 35 comes with version "13.0.0~rc1-1.fc35". An alternative would be to freeze on version 12, but that has different problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it would be cumbersome for our developers which are on Fedora 35 to use a clang that they cannot easily install). The (differently painful) solution is to reformat from time to time, as we switch to a new Fedora (and thus clang) version. Usually we would expect that such a reformatting brings minor changes. But this time, the changes are huge. That is mentioned in the release notes [1] as Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353) [1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
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);
libnm: reserve size for properties_override array For settings with many properties, pre-allocate a larger buffer via _nm_sett_info_property_override_create_array_sized(). The buffer is larger than needed, so when we add more properties it still works. In any case, GArray will grow automatically, so getting this wrong is not fatal (just suboptimal).
2023-10-25 16:10:06 +02:00
GArray *properties_override = _nm_sett_info_property_override_create_array_sized(35);
connection: deprecate the NMSettingConnection Master property To embrace inclusive language, deprecate the NMSettingConnection Master property and introduce Controller property.
2023-11-29 14:43:43 +01:00
guint prop_idx;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
object_class->get_property = get_property;
libnm-core: reorder code in settings Order the code in our common way. No other changes. - ensure to include the main header first (directly after "nm-default.h"). - reorder function definitions: get_property(), set_property(), *_init(), *_new(), finalize(), *_class_init().
2019-01-11 08:32:54 +01:00
object_class->set_property = set_property;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
object_class->finalize = finalize;
libnm: refactor NMSettingClass.compare_property() to NMSettInfoPropertType.compare_fcn() NMSettingClass.compare_property() will be dropped.
2021-06-29 14:37:16 +02:00
setting_class->verify = verify;
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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---
*/
libnm: refactor NMSettingClass.compare_property() to NMSettInfoPropertType.compare_fcn() NMSettingClass.compare_property() will be dropped.
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,
libnm: always set from_dbus_fcn() property hook When looking at a property, it should always be clear how it is handled. Also the "default" action should be an explicit hook. Add _nm_setting_property_from_dbus_fcn_gprop() and set that as from_dbus_fcn() callback to handle the "default" case which us build around g_object_set_property(). While this adds lines of code, I think it makes the code easier to understand. Basically, to convert a GVariant to a property, now all properties call their from_dbus_fcn() handler, there is no special casing. And the gprop-hook is only called for properties that are using _nm_setting_property_from_dbus_fcn_gprop(). So, you can reason about these two functions at separate layers.
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,
libnm: add from_dbus_fcn for direct properties There is a quest to move away from the GObject/GValue based setters. Add _nm_setting_property_from_dbus_fcn_direct(), which can parse the GVariant and use the direct_type to set the property. Note that for backward compatibility, we still need _nm_property_variant_to_gvalue() to convert alternative GVariant types to the destination value. This means, as before, on the D-Bus API a property of a certain type can be represented as various D-Bus types.
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),
libnm: refactor NMSettingClass.compare_property() to NMSettInfoPropertType.compare_fcn() NMSettingClass.compare_property() will be dropped.
2021-06-29 14:37:16 +02:00
NMSettingConnectionPrivate,
id);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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
glib-aux/trivial: rename NMUuid API
2021-05-02 21:32:31 +02:00
* nm_uuid_generate_from_string_str().
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
**/
nmcli: allow changing the UUID of a profile in offline mode It is useful to modify the UUID in offline mode. Otherwise, it's cumbersome to clone a profile, because the cloned profile will have the same UUID (and NetworkManager cannot load them both at the same time). umask 077 nmcli --offline connection modify \ connection.id profile2 \ connection.uuid new \ < /etc/NetworkManager/system-connections/profile1.nmconnection \ > /etc/NetworkManager/system-connections/profile2.nmconnection \ The doctext doesn't actually work for `man nm-settings-nmcli`. The generation of our docs is still an incomprehensible mess that needs fixing.
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(+)
docs: fix a typo in ifcfg-rh documenation
2014-11-20 13:18:32 +01:00
* description: UUID for the connection profile. When missing, NetworkManager
libnm: add NMSettingConnection:stable-id property This new property be used as token to generate stable-ids instead of the connection's UUID. Later, this will be used by ipv6.addr-gen-mode=stable-privacy, ethernet.cloned-mac-address=stable, and wifi.cloned-mac-address=stable setting. Those generate stable addresses based on the connection's UUID, but allow to use the stable-id instead. This allows multiple connections to generate the same addresses -- on the same machine, because in the above cases a machine dependant key is also hashed.
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---
*/
libnm: use _nm_setting_property_define_direct_string()
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: add NMSettingConnection:stable-id property This new property be used as token to generate stable-ids instead of the connection's UUID. Later, this will be used by ipv6.addr-gen-mode=stable-privacy, ethernet.cloned-mac-address=stable, and wifi.cloned-mac-address=stable setting. Those generate stable addresses based on the connection's UUID, but allow to use the stable-id instead. This allows multiple connections to generate the same addresses -- on the same machine, because in the above cases a machine dependant key is also hashed.
2016-06-21 16:41:05 +02:00
/**
* NMSettingConnection:stable-id:
*
all: add stable-id specifier "${DEVICE}" Add new stable-id specifier "${DEVICE}" to explicitly declare that the connection's identity differs per-device. Note that for settings like "ipv6.addr-gen-mode=stable" we already hash the interface's name. So, in combination with addr-gen-mode, using this specifier has no real use. But for example, we don't do that for "ipv4.dhcp-client-id=stable". Point being, in various context we possibly already include a per-device token into the generation algorithm. But that is not the case for all contexts and uses. Especially the DHCPv4 client identifier is supposed to differ between interfaces (according to RFC). We don't do that by default with "ipv4.dhcp-client-id=stable", but with "${DEVICE}" can can now be configured by the user. Note that the fact that the client-id is the same accross interfaces, is not a common problem, because profiles are usually restricted to one device via connection.interface-name.
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.
libnm: add NMSettingConnection:stable-id property This new property be used as token to generate stable-ids instead of the connection's UUID. Later, this will be used by ipv6.addr-gen-mode=stable-privacy, ethernet.cloned-mac-address=stable, and wifi.cloned-mac-address=stable setting. Those generate stable addresses based on the connection's UUID, but allow to use the stable-id instead. This allows multiple connections to generate the same addresses -- on the same machine, because in the above cases a machine dependant key is also hashed.
2016-06-21 16:41:05 +02:00
*
libnm/docs: mention "ipv[46].dhcp-iaid=stable" to be affected by "connection.stable-id"
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.
dhcp: add support for special ipv4.dhcp-client-id types "mac", "perm-mac", and "stable"
2018-02-14 17:01:56 +01:00
*
all: add stable-id specifier "${DEVICE}" Add new stable-id specifier "${DEVICE}" to explicitly declare that the connection's identity differs per-device. Note that for settings like "ipv6.addr-gen-mode=stable" we already hash the interface's name. So, in combination with addr-gen-mode, using this specifier has no real use. But for example, we don't do that for "ipv4.dhcp-client-id=stable". Point being, in various context we possibly already include a per-device token into the generation algorithm. But that is not the case for all contexts and uses. Especially the DHCPv4 client identifier is supposed to differ between interfaces (according to RFC). We don't do that by default with "ipv4.dhcp-client-id=stable", but with "${DEVICE}" can can now be configured by the user. Note that the fact that the client-id is the same accross interfaces, is not a common problem, because profiles are usually restricted to one device via connection.interface-name.
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.
libnm/docs: add reference to secret-key in description for stable-id
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.
device: support dynamic "connection.stable-id" in form of text-substitution Usecase: when connecting to a public Wi-Fi with MAC address randomization ("wifi.cloned-mac-address=random") you get on every re-connect a new IP address due to the changing MAC address. "wifi.cloned-mac-address=stable" is the solution for that. But that means, every time when reconnecting to this network, the same ID will be reused. We want an ID that is stable for a while, but at a later point a new ID should e generated when revisiting the Wi-Fi network. Extend the stable-id to become dynamic and support templates/substitutions. Currently supported is "${CONNECTION}", "${BOOT}" and "${RANDOM}". Any unrecognized pattern is treated verbaim/untranslated. "$$" is treated special to allow escaping the '$' character. This allows the user to still embed verbatim '$' characters with the guarantee that future versions of NetworkManager will still generate the same ID. Of course, a user could just avoid '$' in the stable-id unless using it for dynamic substitutions. Later we might want to add more recognized substitutions. For example, it could be useful to generate new IDs based on the current time. The ${} syntax is extendable to support arguments like "${PERIODIC:weekly}". Also allow "connection.stable-id" to be set as global default value. Previously that made no sense because the stable-id was static and is anyway strongly tied to the identity of the connection profile. Now, with dynamic stable-ids it gets much more useful to specify a global default. Note that pre-existing stable-ids don't change and still generate the same addresses -- unless they contain one of the new ${} patterns.
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}",
core: support "${NETWORK_SSID}" for connection.stable-id For Wi-Fi profiles, this will encode the SSID in the stable-id. For other profiles, this encodes the connection UUID (but the SSID and the UUID will always result in distinct stable IDs). Also escape the SSID, so that the generated stable-id is always valid UTF-8.
2023-11-14 10:12:10 +01:00
* "${MAC}", "${NETWORK_SSID}", "${BOOT}", "${RANDOM}". These effectively
* create unique IDs per-connection, per-device, per-SSID, 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. "${NETWORK_SSID}" uses the SSID for
* Wi-Fi networks and falls back to "${CONNECTION}" on other networks. Any
* unrecognized patterns following '$' are treated verbatim, however are
* reserved for future use. You are thus advised to avoid '$' or escape it
* as "$$". For example, set it to "${CONNECTION}-${BOOT}-${DEVICE}" to
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
* create a unique id for this connection that changes with every reboot
* and differs depending on the interface where the profile activates.
device: support dynamic "connection.stable-id" in form of text-substitution Usecase: when connecting to a public Wi-Fi with MAC address randomization ("wifi.cloned-mac-address=random") you get on every re-connect a new IP address due to the changing MAC address. "wifi.cloned-mac-address=stable" is the solution for that. But that means, every time when reconnecting to this network, the same ID will be reused. We want an ID that is stable for a while, but at a later point a new ID should e generated when revisiting the Wi-Fi network. Extend the stable-id to become dynamic and support templates/substitutions. Currently supported is "${CONNECTION}", "${BOOT}" and "${RANDOM}". Any unrecognized pattern is treated verbaim/untranslated. "$$" is treated special to allow escaping the '$' character. This allows the user to still embed verbatim '$' characters with the guarantee that future versions of NetworkManager will still generate the same ID. Of course, a user could just avoid '$' in the stable-id unless using it for dynamic substitutions. Later we might want to add more recognized substitutions. For example, it could be useful to generate new IDs based on the current time. The ${} syntax is extendable to support arguments like "${PERIODIC:weekly}". Also allow "connection.stable-id" to be set as global default value. Previously that made no sense because the stable-id was static and is anyway strongly tied to the identity of the connection profile. Now, with dynamic stable-ids it gets much more useful to specify a global default. Note that pre-existing stable-ids don't change and still generate the same addresses -- unless they contain one of the new ${} patterns.
2016-12-18 13:54:26 +01:00
*
all: add stable-id specifier "${DEVICE}" Add new stable-id specifier "${DEVICE}" to explicitly declare that the connection's identity differs per-device. Note that for settings like "ipv6.addr-gen-mode=stable" we already hash the interface's name. So, in combination with addr-gen-mode, using this specifier has no real use. But for example, we don't do that for "ipv4.dhcp-client-id=stable". Point being, in various context we possibly already include a per-device token into the generation algorithm. But that is not the case for all contexts and uses. Especially the DHCPv4 client identifier is supposed to differ between interfaces (according to RFC). We don't do that by default with "ipv4.dhcp-client-id=stable", but with "${DEVICE}" can can now be configured by the user. Note that the fact that the client-id is the same accross interfaces, is not a common problem, because profiles are usually restricted to one device via connection.interface-name.
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.
core: prefer connection.stable-id to generate IPv6 stable privacy addresses The Network_ID for generating RFC 7217 stable privacy IPv6 addresses is by default the UUID of the connection. Alternatively, prefer "connection.stable-id" as Network_ID to generate the stable addresses. This allows to configure a set of connections that all use the same Network_ID for generating stable addresses. Note that the stable-id and the UUID do no overlap, that is two connections [connection] uuid=uuid1 stable-id= and [connection] uuid=uuid2 stable-id=uuid1 generate distinct addresses.
2016-06-21 18:07:56 +02:00
*
libnm: add NMSettingConnection:stable-id property This new property be used as token to generate stable-ids instead of the connection's UUID. Later, this will be used by ipv6.addr-gen-mode=stable-privacy, ethernet.cloned-mac-address=stable, and wifi.cloned-mac-address=stable setting. Those generate stable addresses based on the connection's UUID, but allow to use the stable-id instead. This allows multiple connections to generate the same addresses -- on the same machine, because in the above cases a machine dependant key is also hashed.
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---
*/
libnm: add direct_offset for string properties And, as an example used for property "connection.stable-id".
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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---
*/
libnm: use _nm_setting_property_define_direct_string()
2021-06-28 17:28:21 +02:00
_nm_setting_property_define_direct_string_full(
libnm/trivial: rename _properties_override_add_*() to _nm_properties_override_*() These macros/functions are in a header file. Everything in a header file should have an "nm" prefix. Rename.
2019-09-22 15:32:04 +02:00
properties_override,
libnm: use _nm_setting_property_define_string() for string NMSetting properties
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,
libnm: use _nm_setting_property_define_direct_string()
2021-06-28 17:28:21 +02:00
.direct_type = NM_VALUE_TYPE_STRING,
libnm: implement "direct" properties for compare_fcn()
2021-06-29 18:18:06 +02:00
.compare_fcn = _nm_setting_property_compare_fcn_direct,
libnm: use _nm_setting_property_define_direct_string()
2021-06-28 17:28:21 +02:00
.to_dbus_fcn = _nm_setting_property_to_dbus_fcn_direct,
libnm: use _nm_setting_property_define_string() for string NMSetting properties
2021-06-17 22:53:52 +02:00
.missing_from_dbus_fcn =
libnm: always set from_dbus_fcn() property hook When looking at a property, it should always be clear how it is handled. Also the "default" action should be an explicit hook. Add _nm_setting_property_from_dbus_fcn_gprop() and set that as from_dbus_fcn() callback to handle the "default" case which us build around g_object_set_property(). While this adds lines of code, I think it makes the code easier to understand. Basically, to convert a GVariant to a property, now all properties call their from_dbus_fcn() handler, there is no special casing. And the gprop-hook is only called for properties that are using _nm_setting_property_from_dbus_fcn_gprop(). So, you can reason about these two functions at separate layers.
2021-06-30 00:05:49 +02:00
nm_setting_connection_no_interface_name,
libnm: add from_dbus_fcn for direct properties There is a quest to move away from the GObject/GValue based setters. Add _nm_setting_property_from_dbus_fcn_direct(), which can parse the GVariant and use the direct_type to set the property. Note that for backward compatibility, we still need _nm_property_variant_to_gvalue() to convert alternative GVariant types to the destination value. This means, as before, on the D-Bus API a property of a certain type can be represented as various D-Bus types.
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),
libnm: use _nm_setting_property_define_direct_string()
2021-06-28 17:28:21 +02:00
NMSettingConnectionPrivate,
interface_name);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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---
*/
libnm: use _nm_setting_property_define_direct_string()
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,
libnm: make "connection.type" property a NMRefString
2022-01-05 17:05:00 +01:00
type,
.direct_string_is_refstr = TRUE);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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
libnm-core: clarify the meaning of the connection.permissions property https://bugzilla.redhat.com/show_bug.cgi?id=1457939
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".
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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(+)
libnm-core: clarify the meaning of the connection.permissions property https://bugzilla.redhat.com/show_bug.cgi?id=1457939
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---
*/
libnm: use _nm_setting_property_define_gprop_strv_oldstyle() Use _nm_setting_property_define_gprop_strv_oldstyle() for all existing (remaining) G_TYPE_STRV properties. The benefit is that the properties_override array already lists the property, and we don't need special hacks in _nm_setting_class_commit() to initialize those properties. Also, this style is discouraged. We can now easier find all properties that should be reworked.
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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.
libnm-core: improve documentation for autoconnect and autoconnect-slaves properties
2018-04-12 11:44:58 +02:00
*
libnm/docs: better explain "connection.autoconnect{,-priority}"
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.
*
libnm-core: improve documentation for autoconnect and autoconnect-slaves properties
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.
libnm/doc: clarify behavior for autoconnect in `man nm-settings`
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.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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---
*/
libnm: add direct_offset for boolean properties Introduce a new mechanism for how to handle properties generically. We have NMSettInfoSetting, NMSettInfoProperty and NMSettInfoPropertType with meta data about settings and their properties. For example, we have a simple boolean property. Then (usually) we have a boolean GParamSpec, and a plain boolean field in the NMSetting's private data. We need very little to get (and convert to keyfile, GVariant), set (from keyfile, GVariant) and compare this property. All we need to know, is the GParamSpec and the offset of the bool field. Introduce a new mechanism for that, and as example implement NM_SETTING_CONNECTION_AUTOCONNECT property this way. Note that this patch only changes the to_dbus_fcn() for the boolean property. But this opens up all kind of further improvements. What we eventually also can do is replace GObjectClass.get_property() with a generic variant, that knows how to get and set the property.
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: add NMSettingConnection:autoconnect-priority setting The autoconnect priority has only any relevance, if the connection is autoconnect too. The priority defaults to zero, with higher numbers meaning preferred. The valid range is limited to [-999,999]. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-08-25 20:39:40 +02:00
/**
* NMSettingConnection:autoconnect-priority:
*
libnm/docs: better explain "connection.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.
libnm: add NMSettingConnection:autoconnect-priority setting The autoconnect priority has only any relevance, if the connection is autoconnect too. The priority defaults to zero, with higher numbers meaning preferred. The valid range is limited to [-999,999]. Signed-off-by: Thomas Haller <thaller@redhat.com>
2014-08-25 20:39:40 +02:00
**/
libnm-core: document AUTOCONNECT_PRIORITY for ifcfg-rh
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---
*/
libnm: use direct properties for NMSettingConnection
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm-core: introduce connection.autoconnect-retries property While technically it's already possible to implement a fail-over mechanism using multiple connections (for example, defining a higher priority DHCP connection with short DHCP timeout and a lower priority one with static address), in practice this doesn't work well as we try to autoactivate each connection 4 times before switching to the next one. Introduce a connection.autoconnect-retries property that can be used to change the number of retries. The special value 0 means infinite and can be used to try the connection forever. A -1 value means the global configured default, which is equal to 4 unless overridden. https://bugzilla.gnome.org/show_bug.cgi?id=763524
2016-10-08 10:27:15 +02:00
/**
* NMSettingConnection:autoconnect-retries:
*
all: fix typos in documentation, translated strings and comments https://bugzilla.gnome.org/show_bug.cgi?id=783173
2017-05-28 17:34:31 +03:00
* The number of times a connection should be tried when autoactivating before
libnm-core: introduce connection.autoconnect-retries property While technically it's already possible to implement a fail-over mechanism using multiple connections (for example, defining a higher priority DHCP connection with short DHCP timeout and a lower priority one with static address), in practice this doesn't work well as we try to autoactivate each connection 4 times before switching to the next one. Introduce a connection.autoconnect-retries property that can be used to change the number of retries. The special value 0 means infinite and can be used to try the connection forever. A -1 value means the global configured default, which is equal to 4 unless overridden. https://bugzilla.gnome.org/show_bug.cgi?id=763524
2016-10-08 10:27:15 +02:00
* giving up. Zero means forever, -1 means the global default (4 times if not
docs: clearify documentation of connection.autoconnect-retries
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.
libnm-core: introduce connection.autoconnect-retries property While technically it's already possible to implement a fail-over mechanism using multiple connections (for example, defining a higher priority DHCP connection with short DHCP timeout and a lower priority one with static address), in practice this doesn't work well as we try to autoactivate each connection 4 times before switching to the next one. Introduce a connection.autoconnect-retries property that can be used to change the number of retries. The special value 0 means infinite and can be used to try the connection forever. A -1 value means the global configured default, which is equal to 4 unless overridden. https://bugzilla.gnome.org/show_bug.cgi?id=763524
2016-10-08 10:27:15 +02:00
*/
ifcfg-rh: support the autoconnect-retries property
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---
*/
libnm: use direct properties for NMSettingConnection
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
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.
libnm/doc: fix example for MULTI_CONNECT ifcfg-rh setting
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---
*/
libnm: use direct properties for NMSettingConnection
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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).
**/
libnm-core: cleanup NMSetting's class initialization Unify the coding style for class-init functions in libnm-core. Also make use of obj_properties, NM_GOBJECT_PROPERTIES_DEFINE(), and _notify().
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);
libnm/trivial: rename _properties_override_add_*() to _nm_properties_override_*() These macros/functions are in a header file. Everything in a header file should have an "nm" prefix. Rename.
2019-09-22 15:32:04 +02:00
_nm_properties_override_gobj(
properties_override,
obj_properties[PROP_TIMESTAMP],
libnm: add and use NM_SETT_INFO_PROPERT_TYPE_DBUS() macro
2021-06-18 09:44:46 +02:00
NM_SETT_INFO_PROPERT_TYPE_DBUS(G_VARIANT_TYPE_UINT64,
libnm: always set from_dbus_fcn() property hook When looking at a property, it should always be clear how it is handled. Also the "default" action should be an explicit hook. Add _nm_setting_property_from_dbus_fcn_gprop() and set that as from_dbus_fcn() callback to handle the "default" case which us build around g_object_set_property(). While this adds lines of code, I think it makes the code easier to understand. Basically, to convert a GVariant to a property, now all properties call their from_dbus_fcn() handler, there is no special casing. And the gprop-hook is only called for properties that are using _nm_setting_property_from_dbus_fcn_gprop(). So, you can reason about these two functions at separate layers.
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));
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/**
* NMSettingConnection:read-only:
*
libnm: make "connection.read-only" as deprecated This has no more meaning, and is always false.
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.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
**/
libnm: use _nm_setting_property_define_direct_boolean() There is a new way how to implement default boolean properties. Use it.
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,
libnm: make "connection.read-only" as deprecated This has no more meaning, and is always false.
2023-03-14 08:48:07 +01:00
read_only,
.is_deprecated = TRUE, );
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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.
libnm: mark properties that take effect immediately on active connection (REAPPLY_IMMEDIATELY) The flag is still unused.
2015-09-18 17:21:34 +02:00
*
* When updating this property on a currently activated connection,
* the change takes effect immediately.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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---
*/
libnm: use _nm_setting_property_define_direct_string()
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/**
* NMSettingConnection:master:
*
* Interface name of the master device or UUID of the master connection.
connection: deprecate the NMSettingConnection Master property To embrace inclusive language, deprecate the NMSettingConnection Master property and introduce Controller property.
2023-11-29 14:43:43 +01:00
*
* Deprecated 1.46. Use #NMSettingConnection:controller instead, this is just an alias.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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: master
ifcfg-rh: write the master device name even if the master property is an UUID We used MASTER, BRIDGE and TEAM_MASTER keys for a differnet purpose than the network.service did, confusing the legacy tooling. Let's do our best to write compatible configuration files: * Add *_UUID properties that won't clash with initscripts * Ignore non-*_UUID keys on read if *_UUID is present * If the connection.master is an UUID of a connection with a connection.interface-name, write the uuid into the *_UUID key while setting the non-*_UUID key to the interface name for compatibility https://bugzilla.redhat.com/show_bug.cgi?id=1369091
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
ifcfg-rh: write the master device name even if the master property is an UUID We used MASTER, BRIDGE and TEAM_MASTER keys for a differnet purpose than the network.service did, confusing the legacy tooling. Let's do our best to write compatible configuration files: * Add *_UUID properties that won't clash with initscripts * Ignore non-*_UUID keys on read if *_UUID is present * If the connection.master is an UUID of a connection with a connection.interface-name, write the uuid into the *_UUID key while setting the non-*_UUID key to the interface name for compatibility https://bugzilla.redhat.com/show_bug.cgi?id=1369091
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---
*/
connection: deprecate the NMSettingConnection Master property To embrace inclusive language, deprecate the NMSettingConnection Master property and introduce Controller property.
2023-11-29 14:43:43 +01:00
prop_idx = _nm_setting_property_define_direct_string_full(
properties_override,
obj_properties,
NM_SETTING_CONNECTION_MASTER,
PROP_MASTER,
NM_SETTING_PARAM_INFERRABLE | NM_SETTING_PARAM_FUZZY_IGNORE,
NM_SETT_INFO_PROPERT_TYPE_DBUS(G_VARIANT_TYPE_STRING,
.direct_type = NM_VALUE_TYPE_STRING,
.compare_fcn = _nm_setting_property_compare_fcn_direct,
.to_dbus_fcn = _nm_setting_property_to_dbus_fcn_direct,
.from_dbus_fcn = _nm_setting_connection_master_from_dbus, ),
NMSettingConnectionPrivate,
controller,
.is_deprecated = 1);
/**
* NMSettingConnection:controller:
*
* Interface name of the controller device or UUID of the controller connection.
**/
_nm_setting_property_define_direct_string_full(
properties_override,
obj_properties,
NM_SETTING_CONNECTION_CONTROLLER,
PROP_CONTROLLER,
NM_SETTING_PARAM_INFERRABLE | NM_SETTING_PARAM_FUZZY_IGNORE,
NM_SETT_INFO_PROPERT_TYPE_DBUS(G_VARIANT_TYPE_STRING,
.direct_type = NM_VALUE_TYPE_STRING,
.compare_fcn = _nm_setting_property_compare_fcn_direct,
.to_dbus_fcn = _nm_setting_connection_controller_to_dbus,
.from_dbus_fcn =
_nm_setting_connection_controller_from_dbus),
NMSettingConnectionPrivate,
controller,
.direct_also_notify = obj_properties[PROP_MASTER]);
nm_g_array_index(properties_override, NMSettInfoProperty, prop_idx).direct_also_notify =
obj_properties[PROP_CONTROLLER];
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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.
connection: deprecate the NMSettingConnection slave-type property To embrace inclusive language, deprecate the NMSettingConnection slave-type property and introduce port-type property. Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
2024-01-16 13:58:11 +01:00
*
* Deprecated 1.46. Use #NMSettingConnection:port-type instead, this is just an alias.
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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: slave-type
ifcfg-rh: write the master device name even if the master property is an UUID We used MASTER, BRIDGE and TEAM_MASTER keys for a differnet purpose than the network.service did, confusing the legacy tooling. Let's do our best to write compatible configuration files: * Add *_UUID properties that won't clash with initscripts * Ignore non-*_UUID keys on read if *_UUID is present * If the connection.master is an UUID of a connection with a connection.interface-name, write the uuid into the *_UUID key while setting the non-*_UUID key to the interface name for compatibility https://bugzilla.redhat.com/show_bug.cgi?id=1369091
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
ifcfg-rh: write the master device name even if the master property is an UUID We used MASTER, BRIDGE and TEAM_MASTER keys for a differnet purpose than the network.service did, confusing the legacy tooling. Let's do our best to write compatible configuration files: * Add *_UUID properties that won't clash with initscripts * Ignore non-*_UUID keys on read if *_UUID is present * If the connection.master is an UUID of a connection with a connection.interface-name, write the uuid into the *_UUID key while setting the non-*_UUID key to the interface name for compatibility https://bugzilla.redhat.com/show_bug.cgi?id=1369091
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---
*/
connection: deprecate the NMSettingConnection slave-type property To embrace inclusive language, deprecate the NMSettingConnection slave-type property and introduce port-type property. Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
2024-01-16 13:58:11 +01:00
prop_idx = _nm_setting_property_define_direct_string_full(
properties_override,
obj_properties,
NM_SETTING_CONNECTION_SLAVE_TYPE,
PROP_SLAVE_TYPE,
NM_SETTING_PARAM_FUZZY_IGNORE | NM_SETTING_PARAM_INFERRABLE,
NM_SETT_INFO_PROPERT_TYPE_DBUS(G_VARIANT_TYPE_STRING,
.direct_type = NM_VALUE_TYPE_STRING,
.compare_fcn = _nm_setting_property_compare_fcn_direct,
.to_dbus_fcn = _nm_setting_property_to_dbus_fcn_direct,
.from_dbus_fcn =
_nm_setting_connection_slave_type_from_dbus, ),
NMSettingConnectionPrivate,
port_type,
.is_deprecated = 1);
/**
* NMSettingConnection:port-type:
*
* Setting name of the device type of this port's controller connection (eg,
* %NM_SETTING_BOND_SETTING_NAME), or %NULL if this connection is not a
* port.
*
* Since: 1.46
**/
_nm_setting_property_define_direct_string_full(
properties_override,
obj_properties,
NM_SETTING_CONNECTION_PORT_TYPE,
PROP_PORT_TYPE,
NM_SETTING_PARAM_FUZZY_IGNORE | NM_SETTING_PARAM_INFERRABLE,
NM_SETT_INFO_PROPERT_TYPE_DBUS(G_VARIANT_TYPE_STRING,
.direct_type = NM_VALUE_TYPE_STRING,
.compare_fcn = _nm_setting_property_compare_fcn_direct,
.to_dbus_fcn = _nm_setting_connection_port_type_to_dbus,
.from_dbus_fcn =
_nm_setting_connection_port_type_from_dbus, ),
NMSettingConnectionPrivate,
port_type,
.direct_also_notify = obj_properties[PROP_SLAVE_TYPE]);
nm_g_array_index(properties_override, NMSettInfoProperty, prop_idx).direct_also_notify =
obj_properties[PROP_PORT_TYPE];
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: add autoconnect-slaves property to NMSettingConnection The property is used for controlling whether slaves should be brought up with a master connection. If 0, activating the master will not activate slaves. But if set to 1, activating the master will bring up slaves as well. The property can have the third state (-1), meaning that the value is default. That is either a value set in the configuration file for the property, or 0.
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
libnm-core: improve documentation for autoconnect and autoconnect-slaves properties
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.
libnm: add autoconnect-slaves property to NMSettingConnection The property is used for controlling whether slaves should be brought up with a master connection. If 0, activating the master will not activate slaves. But if set to 1, activating the master will bring up slaves as well. The property can have the third state (-1), meaning that the value is default. That is either a value set in the configuration file for the property, or 0.
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
man: fix docu of AUTOCONNECT_SLAVES variable in nm-settings-ifcfg-rh Fixes: 6caafab258762713a354cf37591510b6ac29936c https://bugzilla.redhat.com/show_bug.cgi?id=1492912
2017-09-19 08:34:48 +02:00
* variable: AUTOCONNECT_SLAVES(+)
ifcfg-rh: read/write autoconnect-slaves property as AUTOCONNECT_SLAVES AUTOCONNECT_SLAVES is an NetworkManager extension. initscripts always activate slaves with the master connection for bond and team, and doesn't activate automatically slaves for bridge. NetworkManager behaviour is controlled by this variable. If the variable is missing the default value from configuration file is used.
2015-05-06 10:59:11 +02:00
* default: missing variable means global default
libnm: add autoconnect-slaves property to NMSettingConnection The property is used for controlling whether slaves should be brought up with a master connection. If 0, activating the master will not activate slaves. But if set to 1, activating the master will bring up slaves as well. The property can have the third state (-1), meaning that the value is default. That is either a value set in the configuration file for the property, or 0.
2015-05-06 10:54:35 +02:00
* description: Whether slaves of this connection should be auto-connected
* when this connection is activated.
* ---end---
*/
libnm: refactor some NMSetting to use direct properties "direct" properties are the latest preferred way to implement GObject base properties. That way, the property meta data tracks the "direct_type" and the offset where to find the data in the struct. That way, we can automatically - initialize the default values - free during finalize - implement get_property()/set_property() Also, the other settings operations (compare, to/from D-Bus) are implemented more efficiently and don't need to go through g_object_get_property()/GValue API.
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
/**
* NMSettingConnection:secondaries:
*
* List of connection UUIDs that should be activated when the base
all: fix typo in man pages There should be a comma after 'Otherwise' and 'Currently'. https://bugzilla.redhat.com/show_bug.cgi?id=1852452 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/560
2020-07-01 17:20:40 -04:00
* connection itself is activated. Currently, only VPN connections are
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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---
*/
libnm: rework strv properties of NMSetting as "direct" properties Make use of direct strv property in some cases. It doesn't work for other cases yet, because they are implemented differently, and porting them is more effort and needs to be done one by one. The goal is to have a unified, standard implementation for our properties. One that requires a minimal amount of property-specific code. For strv properties, that is a bit more cumbersome, because usually there are multiple C accessor functions. Still, make an effort to have a "direct" strv property. What this also gives, is that we no longer need to clone the strv array for various operations. We know how to access the data, and can do it directly without g_object_get()/g_object_set().
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
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---
*/
libnm: use direct properties for NMSettingConnection
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm-core: add 'metered' property to NMSettingConnection Add a 'metered' enum property to NMSettingConnection with possible values: unknown,yes,no. The value indicates the presence of limitations in the amount of traffic flowing through the connection.
2015-04-27 17:45:53 +02:00
/**
* NMSettingConnection:metered:
*
* Whether the connection is metered.
*
libnm: mark properties that take effect immediately on active connection (REAPPLY_IMMEDIATELY) The flag is still unused.
2015-09-18 17:21:34 +02:00
* When updating this property on a currently activated connection,
* the change takes effect immediately.
*
libnm-core: add 'metered' property to NMSettingConnection Add a 'metered' enum property to NMSettingConnection with possible values: unknown,yes,no. The value indicates the presence of limitations in the amount of traffic flowing through the connection.
2015-04-27 17:45:53 +02:00
* Since: 1.2
**/
ifcfg-rh: add support for CONNECTION_METERED
2015-05-29 17:41:21 +02:00
/* ---ifcfg-rh---
* property: metered
man/ifcfg-rh: mark some ifcfg-rh variables with (+) as NM extensions
2016-12-09 22:19:48 +01:00
* variable: CONNECTION_METERED(+)
ifcfg-rh: add support for 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---
*/
libnm: refactor some NMSetting to use direct properties "direct" properties are the latest preferred way to implement GObject base properties. That way, the property meta data tracks the "direct_type" and the offset where to find the data in the struct. That way, we can automatically - initialize the default values - free during finalize - implement get_property()/set_property() Also, the other settings operations (compare, to/from D-Bus) are implemented more efficiently and don't need to go through g_object_get_property()/GValue API.
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: add 'lldp' property to NMSettingConnection Add the 'lldp' property to NMSettingConnection, which specifies whether the reception and parsing of LLDP frames to discover neighbor devices should be enabled.
2015-10-07 11:48:30 +02:00
/**
* NMSettingConnection:lldp:
*
* Whether LLDP is enabled for the connection.
*
* Since: 1.2
**/
ifcfg-rh: add support for 'LLDP' connection property
2015-10-08 18:26:45 +02:00
/* ---ifcfg-rh---
* property: lldp
man/ifcfg-rh: mark some ifcfg-rh variables with (+) as NM extensions
2016-12-09 22:19:48 +01:00
* variable: LLDP(+)
ifcfg-rh: add support for 'LLDP' connection property
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---
*/
libnm: use direct properties for NMSettingConnection
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
all: move setting 802-1x.auth-retries to connection.auth-retries The number of authentication retires is useful also for passwords aside 802-1x settings. For example, src/devices/wifi/nm-device-wifi.c also has a retry counter and uses a hard-coded value of 3. Move the setting, so that it can be used in general. Although it is still not implemented for other settings. This is an API and ABI break.
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.
*
all: fix typo in man pages There should be a comma after 'Otherwise' and 'Currently'. https://bugzilla.redhat.com/show_bug.cgi?id=1852452 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/560
2020-07-01 17:20:40 -04:00
* Currently, this only applies to 802-1x authentication.
all: move setting 802-1x.auth-retries to connection.auth-retries The number of authentication retires is useful also for passwords aside 802-1x settings. For example, src/devices/wifi/nm-device-wifi.c also has a retry counter and uses a hard-coded value of 3. Move the setting, so that it can be used in general. Although it is still not implemented for other settings. This is an API and ABI break.
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---
*/
libnm: use direct properties for NMSettingConnection
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
mdns: add new connection property. Add support for mDNS as a connection-level property. Update ifcfg-rh and keyfile plugins to support it.
2017-11-10 14:49:27 +02:00
/**
* NMSettingConnection:mdns:
*
* Whether mDNS is enabled for the connection.
*
doc: clarify default values for ipv4.mdns and ipv4.llmnr settings LLMNR and mDNS settings can have their global default value configured in "NetworkManager.conf". Global default values should work the way that all regular values of the property can be configured explicitly in the connection profile. The special "default" value only indicates to allow lookup of the global default, but it should not have a meaning of its own. Note that if mDNS/LLMNR settings are left unspecified, we will set the argument to SetLinkMulticastDNS() and SetLinkLLMNR() functions to "", which means that systemd-resolved decides on a default. Also, depending on the DNS plugin, the default value differs. This is all fine however. In this case, the ultimate default value depends on other things (like the DNS plugin), but each possible value is in fact explicitly configurable. We also do that for "ipv6.ip6-privacy". Anyway, cleanup the documentation a bit and try to better explain what the default is.
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").
mdns: add new connection property. Add support for mDNS as a connection-level property. Update ifcfg-rh and keyfile plugins to support it.
2017-11-10 14:49:27 +02:00
*
all: fix typo in man pages There should be a comma after 'Otherwise' and 'Currently'. https://bugzilla.redhat.com/show_bug.cgi?id=1852452 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/560
2020-07-01 17:20:40 -04:00
* This feature requires a plugin which supports mDNS. Otherwise, the
doc: clarify default values for ipv4.mdns and ipv4.llmnr settings LLMNR and mDNS settings can have their global default value configured in "NetworkManager.conf". Global default values should work the way that all regular values of the property can be configured explicitly in the connection profile. The special "default" value only indicates to allow lookup of the global default, but it should not have a meaning of its own. Note that if mDNS/LLMNR settings are left unspecified, we will set the argument to SetLinkMulticastDNS() and SetLinkLLMNR() functions to "", which means that systemd-resolved decides on a default. Also, depending on the DNS plugin, the default value differs. This is all fine however. In this case, the ultimate default value depends on other things (like the DNS plugin), but each possible value is in fact explicitly configurable. We also do that for "ipv6.ip6-privacy". Anyway, cleanup the documentation a bit and try to better explain what the default is.
2019-12-10 16:39:44 +01:00
* setting has no effect. One such plugin is dns-systemd-resolved.
libnm: use direct properties for NMSettingConnection
2021-07-13 17:37:08 +02:00
*
mdns: add new connection property. Add support for mDNS as a connection-level property. Update ifcfg-rh and keyfile plugins to support it.
2017-11-10 14:49:27 +02:00
* Since: 1.12
**/
/* ---ifcfg-rh---
* property: mdns
libnm-core: fix documentation for connection.mdns After an update of the connection.mdns property, a reactivation is needed to apply the new value. Also, the ifcfg-rh variable name was wrong. Fixes: 2e2ff6f27aa1bfa7a27d49980b319873240ec84b
2018-08-31 15:18:48 +02:00
* variable: MDNS(+)
mdns: add new connection property. Add support for mDNS as a connection-level property. Update ifcfg-rh and keyfile plugins to support it.
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
libnm-core: fix documentation for connection.mdns After an update of the connection.mdns property, a reactivation is needed to apply the new value. Also, the ifcfg-rh variable name was wrong. Fixes: 2e2ff6f27aa1bfa7a27d49980b319873240ec84b
2018-08-31 15:18:48 +02:00
* example: MDNS=yes
mdns: add new connection property. Add support for mDNS as a connection-level property. Update ifcfg-rh and keyfile plugins to support it.
2017-11-10 14:49:27 +02:00
* ---end---
*/
libnm: use direct properties for NMSettingConnection
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm-core: add connection.llmnr property
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.
*
doc: clarify default values for ipv4.mdns and ipv4.llmnr settings LLMNR and mDNS settings can have their global default value configured in "NetworkManager.conf". Global default values should work the way that all regular values of the property can be configured explicitly in the connection profile. The special "default" value only indicates to allow lookup of the global default, but it should not have a meaning of its own. Note that if mDNS/LLMNR settings are left unspecified, we will set the argument to SetLinkMulticastDNS() and SetLinkLLMNR() functions to "", which means that systemd-resolved decides on a default. Also, depending on the DNS plugin, the default value differs. This is all fine however. In this case, the ultimate default value depends on other things (like the DNS plugin), but each possible value is in fact explicitly configurable. We also do that for "ipv6.ip6-privacy". Anyway, cleanup the documentation a bit and try to better explain what the default is.
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").
libnm-core: add connection.llmnr property
2018-08-31 10:48:18 +02:00
*
all: fix typo in man pages There should be a comma after 'Otherwise' and 'Currently'. https://bugzilla.redhat.com/show_bug.cgi?id=1852452 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/560
2020-07-01 17:20:40 -04:00
* This feature requires a plugin which supports LLMNR. Otherwise, the
doc: clarify default values for ipv4.mdns and ipv4.llmnr settings LLMNR and mDNS settings can have their global default value configured in "NetworkManager.conf". Global default values should work the way that all regular values of the property can be configured explicitly in the connection profile. The special "default" value only indicates to allow lookup of the global default, but it should not have a meaning of its own. Note that if mDNS/LLMNR settings are left unspecified, we will set the argument to SetLinkMulticastDNS() and SetLinkLLMNR() functions to "", which means that systemd-resolved decides on a default. Also, depending on the DNS plugin, the default value differs. This is all fine however. In this case, the ultimate default value depends on other things (like the DNS plugin), but each possible value is in fact explicitly configurable. We also do that for "ipv6.ip6-privacy". Anyway, cleanup the documentation a bit and try to better explain what the default is.
2019-12-10 16:39:44 +01:00
* setting has no effect. One such plugin is dns-systemd-resolved.
libnm-core: add connection.llmnr property
2018-08-31 10:48:18 +02:00
*
* Since: 1.14
**/
ifcfg-rh: add support for connection.llmnr
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---
*/
libnm: use direct properties for NMSettingConnection
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm-core: Add connection.dns-over-tls property
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
**/
ifcfg-rh: add support for connection.dns-over-tls
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---
*/
libnm-core: Add connection.dns-over-tls property
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);
all: add NMMptcpFlags and connection.mptcp-flags property
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
all: drop various NMMptcpFlags The default behavior might be sufficient. Drop those flags for now, and figure out a good solution when we have an actual use-case.
2022-08-05 15:30:38 +02:00
* that are not included by default). The idea is that in the future we could have
all: add NMMptcpFlags and connection.mptcp-flags property
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
all: drop various NMMptcpFlags The default behavior might be sufficient. Drop those flags for now, and figure out a good solution when we have an actual use-case.
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.
all: add NMMptcpFlags and connection.mptcp-flags property
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.
all: add NMMptcpFlags and connection.mptcp-flags property
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),
all: add NMMptcpFlags and connection.mptcp-flags property
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.
all: add NMMptcpFlags and connection.mptcp-flags property
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.
*
all: drop various NMMptcpFlags The default behavior might be sufficient. Drop those flags for now, and figure out a good solution when we have an actual use-case.
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).
*
all: add NMMptcpFlags and connection.mptcp-flags property
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);
libnm,cli,ifcfg-rh: add connection:wait-device-timeout property Initscripts already honor the DEVTIMEOUT variable (rh #1171917). Don't make this a property only supported by initscripts. Every useful property should also be supported by keyfile and it should be accessible via D-Bus. Also, I will soon drop NMSIfcfgConnection, so handling this would require extra code. It's easier when DEVTIMEOUT is a regular property of the connection profile. The property is not yet implemented. ifcfg-rh still uses the old implementation, and keyfile is not yet adjusted. Since both keyfile and ifcfg-rh will both be rewritten soon, this property will be implemented then.
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.
libnm,cli,ifcfg-rh: add connection:wait-device-timeout property Initscripts already honor the DEVTIMEOUT variable (rh #1171917). Don't make this a property only supported by initscripts. Every useful property should also be supported by keyfile and it should be accessible via D-Bus. Also, I will soon drop NMSIfcfgConnection, so handling this would require extra code. It's easier when DEVTIMEOUT is a regular property of the connection profile. The property is not yet implemented. ifcfg-rh still uses the old implementation, and keyfile is not yet adjusted. Since both keyfile and ifcfg-rh will both be rewritten soon, this property will be implemented then.
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---
*/
libnm: use direct properties for NMSettingConnection
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
dhcp: add support for MUD URL (RFC 8520) [thaller@redhat.com: rewritten commit message] https://tools.ietf.org/html/rfc8520 https://blog.apnic.net/2019/05/14/protecting-the-internet-of-things-with-mud/ https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/402 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/463
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
dhcp: make connection.mud-url configurable as global connection default Conceptionally, the MUD URL really depends on the device, and not so much the connection profile. That is, when you have a specific IoT device, then this device probably should use the same MUD URL for all profiles (at least by default). We already have a mechanism for that: global connection defaults. Use that. This allows a vendor drop pre-install a file "/usr/lib/NetworkManager/conf.d/10-mud-url.conf" with [connection-10-mud-url] connection.mud-url=https://example.com Note that we introduce the special "connection.mud-url" value "none", to indicate not to use a MUD URL (but also not to consult the global connection default).
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".
dhcp: add support for MUD URL (RFC 8520) [thaller@redhat.com: rewritten commit message] https://tools.ietf.org/html/rfc8520 https://blog.apnic.net/2019/05/14/protecting-the-internet-of-things-with-mud/ https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/402 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/463
2020-04-08 07:30:08 +00:00
*
libnm: fix API version annotation for nm_setting_connection_get_mud_url()
2020-04-24 09:20:25 +02:00
* Since: 1.26
dhcp: add support for MUD URL (RFC 8520) [thaller@redhat.com: rewritten commit message] https://tools.ietf.org/html/rfc8520 https://blog.apnic.net/2019/05/14/protecting-the-internet-of-things-with-mud/ https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/402 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/463
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---
*/
libnm: use _nm_setting_property_define_direct_string()
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);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: support wait-activation-delay property The property wait-activation-delay will delay the activation of an interface the specified amount of milliseconds. Please notice that it could be delayed some milliseconds more due to other events in NetworkManager. This could be used in multiple scenarios where the user needs to define an arbitrary delay e.g LACP bond configure where the LACP negotiation takes a few seconds and traffic is not allowed, so they would like to use nm-online and a setting configured with this new property to wait some seconds. Therefore, when nm-online is finished, LACP bond should be ready to receive traffic. The delay will happen right before the device is ready to be activated. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1248 https://bugzilla.redhat.com/show_bug.cgi?id=2008337
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);
libnm-core: cleanup NMSetting's class initialization Unify the coding style for class-init functions in libnm-core. Also make use of obj_properties, NM_GOBJECT_PROPERTIES_DEFINE(), and _notify().
2019-01-11 08:28:26 +01:00
g_object_class_install_properties(object_class, _PROPERTY_ENUMS_LAST, obj_properties);
all: reformat all with new clang-format style Run: ./contrib/scripts/nm-code-format.sh -i ./contrib/scripts/nm-code-format.sh -i Yes, it needs to run twice because the first run doesn't yet produce the final result. Signed-off-by: Antonio Cardace <acardace@redhat.com>
2020-09-28 16:03:33 +02:00
libnm: extend NMSettInfoSetting with an offset to the private data NMSetting instances either have no private data, they use g_type_add_class_private(), or they embed the private data in the NMSetting struct. In all cases, we can find the private data at a fixed offset. Track that offset in the NMSettInfoSetting meta data. This will be useful, because properties really are stored in simple fields, like a boolean property can be stored in a "bool" field. We will extend the property meta data to track the offset of this property field, but we also need to know where the offset starts.
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));
libnm: add libnm/libnm-core (part 1) This commit begins creating the new "libnm", which will replace libnm-util and libnm-glib. The main reason for the libnm-util/libnm-glib split is that the daemon needs to link to libnm-util (to get NMSettings, NMConnection, etc), but can't link to libnm-glib (because it uses many of the same type names as the NetworkManager daemon. eg, NMDevice). So the daemon links to only libnm-util, but basically all clients link to both. With libnm, there will be only a single client-visible library, and NetworkManager will internally link against a private "libnm-core" containing the parts that used to be in libnm-util. (The "libnm-core" parts still need to be in their own directory so that the daemon can see those header files without also seeing the ones in libnm/ that conflict with its own headers.) [This commit just copies the source code from libnm-util/ to libnm-core/, and libnm-glib/ to libnm/: mkdir -p libnm-core/tests/ mkdir -p libnm/tests/ cp libnm-util/*.[ch] libnm-util/nm-version.h.in libnm-core/ rm -f libnm-core/nm-version.h libnm-core/nm-setting-template.[ch] libnm-core/nm-utils-enum-types.[ch] cp libnm-util/tests/*.[ch] libnm-core/tests/ cp libnm-glib/*.[ch] libnm/ rm -f libnm/libnm_glib.[ch] libnm/libnm-glib-test.c libnm/nm-glib-enum-types.[ch] cp libnm-glib/tests/*.[ch] libnm/tests/ ]
2014-07-24 08:53:33 -04:00
}
Reference in a new issue Copy permalink