NetworkManager/shared/nm-keyfile/nm-keyfile-internal.h

212 lines
7.9 KiB
C
Raw Normal View History

// SPDX-License-Identifier: GPL-2.0+
/*
* Copyright (C) 2008 Novell, Inc.
* Copyright (C) 2015 Red Hat, Inc.
*/
#ifndef __NM_KEYFILE_INTERNAL_H__
#define __NM_KEYFILE_INTERNAL_H__
#if !((NETWORKMANAGER_COMPILATION) & NM_NETWORKMANAGER_COMPILATION_WITH_LIBNM_CORE_INTERNAL)
#error Cannot use this header.
#endif
#include <sys/types.h>
#include "nm-connection.h"
#include "nm-setting-8021x.h"
#include "nm-core-internal.h"
#include "nm-meta-setting.h"
/*****************************************************************************/
#define NM_KEYFILE_CERT_SCHEME_PREFIX_PATH "file://"
#define NM_KEYFILE_CERT_SCHEME_PREFIX_PKCS11 "pkcs11:"
#define NM_KEYFILE_CERT_SCHEME_PREFIX_BLOB "data:;base64,"
char *nm_keyfile_detect_unqualified_path_scheme (const char *base_dir,
gconstpointer pdata,
gsize data_len,
gboolean consider_exists,
gboolean *out_exists);
typedef enum { /*< flags >*/
NM_KEYFILE_HANDLER_FLAGS_NONE = 0,
} NMKeyfileHandlerFlags;
typedef enum {
NM_KEYFILE_HANDLER_TYPE_WARN = 1,
NM_KEYFILE_HANDLER_TYPE_WRITE_CERT = 2,
} NMKeyfileHandlerType;
typedef struct _NMKeyfileHandlerData NMKeyfileHandlerData;
/**
* NMKeyfileReadHandler:
*
* Hook to nm_keyfile_read(). The user might fail the reading by setting
* @error.
*
* Returns: should return TRUE, if the reading was handled. Otherwise,
* a default action will be performed that depends on the @handler_type.
* For %NM_KEYFILE_HANDLER_TYPE_WARN handler_type, the default action is doing nothing.
*/
typedef gboolean (*NMKeyfileReadHandler) (GKeyFile *keyfile,
NMConnection *connection,
NMKeyfileHandlerType handler_type,
NMKeyfileHandlerData *handler_data,
void *user_data);
typedef enum {
NM_KEYFILE_WARN_SEVERITY_DEBUG = 1000,
NM_KEYFILE_WARN_SEVERITY_INFO = 2000,
NM_KEYFILE_WARN_SEVERITY_INFO_MISSING_FILE = 2901,
NM_KEYFILE_WARN_SEVERITY_WARN = 3000,
} NMKeyfileWarnSeverity;
NMConnection *nm_keyfile_read (GKeyFile *keyfile,
const char *base_dir,
NMKeyfileHandlerFlags handler_flags,
NMKeyfileReadHandler handler,
void *user_data,
GError **error);
gboolean nm_keyfile_read_ensure_id (NMConnection *connection,
const char *fallback_id);
gboolean nm_keyfile_read_ensure_uuid (NMConnection *connection,
const char *fallback_uuid_seed);
/*****************************************************************************/
/**
* NMKeyfileWriteHandler:
*
* This is a hook to tweak the serialization.
*
* Handler for certain properties or events that are not entirely contained
* within the keyfile or that might be serialized differently. The @handler_type and
* @handler_data arguments tell which kind of argument we have at hand.
*
* Currently only the handler_type %NM_KEYFILE_HANDLER_TYPE_WRITE_CERT is supported, which provides
* @handler_data as %NMKeyfileHandlerDataWriteCert. However, this handler should be generic enough
* to support other types as well.
*
* This don't have to be only "properties". For example, nm_keyfile_read() uses
* a similar handler to push warnings to the caller.
*
* If the handler raises an error, it should set the @error value. This causes
* the an overall failure.
*
* Returns: whether the issue was handled. If the type was unhandled,
* a default action will be performed. This might be raise an error,
* do some fallback parsing, or do nothing.
*/
typedef gboolean (*NMKeyfileWriteHandler) (NMConnection *connection,
GKeyFile *keyfile,
NMKeyfileHandlerType handler_type,
NMKeyfileHandlerData *handler_data,
void *user_data);
GKeyFile *nm_keyfile_write (NMConnection *connection,
NMKeyfileHandlerFlags handler_flags,
NMKeyfileWriteHandler handler,
void *user_data,
GError **error);
/*****************************************************************************/
/**
* NMKeyfileHandlerDataWarn:
*
* this struct is passed as @handler_data for the @NMKeyfileReadHandler of
* handler_type %NM_KEYFILE_HANDLER_TYPE_WARN.
*/
typedef struct {
NMKeyfileWarnSeverity severity;
char *message;
const char *fmt;
va_list ap;
} NMKeyfileHandlerDataWarn;
/**
* NMKeyfileHandlerDataWriteCert:
*
* this struct is passed as @handler_data for the @NMKeyfileWriteHandler of
* handler_type %NM_KEYFILE_HANDLER_TYPE_WRITE_CERT.
*/
typedef struct {
const NMSetting8021xSchemeVtable *vtable;
} NMKeyfileHandlerDataWriteCert;
struct _NMKeyfileHandlerData {
NMKeyfileHandlerType type;
GError **p_error;
const char *kf_group_name;
const char *kf_key;
NMSetting *cur_setting;
const char *cur_property;
union {
NMKeyfileHandlerDataWarn warn;
NMKeyfileHandlerDataWriteCert write_cert;
};
};
/*****************************************************************************/
void nm_keyfile_handler_data_fail_with_error (NMKeyfileHandlerData *handler_data,
GError *src);
void nm_keyfile_handler_data_get_context (const NMKeyfileHandlerData *handler_data,
const char **out_kf_group_name,
const char **out_kf_key_name,
NMSetting **out_cur_setting,
const char **out_cur_property_name);
void nm_keyfile_handler_data_warn_get (const NMKeyfileHandlerData *handler_data,
const char **out_message,
NMKeyfileWarnSeverity *out_severity);
const char *_nm_keyfile_handler_data_warn_get_message (const NMKeyfileHandlerData *handler_data);
/*****************************************************************************/
char *nm_keyfile_plugin_kf_get_string (GKeyFile *kf, const char *group, const char *key, GError **error);
void nm_keyfile_plugin_kf_set_string (GKeyFile *kf, const char *group, const char *key, const char *value);
int nm_key_file_get_boolean (GKeyFile *kf, const char *group, const char *key, int default_value);
2015-06-08 13:30:30 +02:00
void _nm_keyfile_copy (GKeyFile *dst, GKeyFile *src);
gboolean _nm_keyfile_a_contains_all_in_b (GKeyFile *kf_a, GKeyFile *kf_b);
gboolean _nm_keyfile_equals (GKeyFile *kf_a, GKeyFile *kf_b, gboolean consider_order);
2015-06-08 13:30:30 +02:00
gboolean _nm_keyfile_has_values (GKeyFile *keyfile);
/*****************************************************************************/
settings: rework tracking settings connections and settings plugins Completely rework how settings plugin handle connections and how NMSettings tracks the list of connections. Previously, settings plugins would return objects of (a subtype of) type NMSettingsConnection. The NMSettingsConnection was tightly coupled with the settings plugin. That has a lot of downsides. Change that. When changing this basic relation how settings connections are tracked, everything falls appart. That's why this is a huge change. Also, since I have to largely rewrite the settings plugins, I also added support for multiple keyfile directories, handle in-memory connections only by keyfile plugin and (partly) use copy-on-write NMConnection instances. I don't want to spend effort rewriting large parts while preserving the old way, that anyway should change. E.g. while rewriting ifcfg-rh, I don't want to let it handle in-memory connections because that's not right long-term. -- If the settings plugins themself create subtypes of NMSettingsConnection instances, then a lot of knowledge about tracking connections moves to the plugins. Just try to follow the code what happend during nm_settings_add_connection(). Note how the logic is spread out: - nm_settings_add_connection() calls plugin's add_connection() - add_connection() creates a NMSettingsConnection subtype - the plugin has to know that it's called during add-connection and not emit NM_SETTINGS_PLUGIN_CONNECTION_ADDED signal - NMSettings calls claim_connection() which hocks up the new NMSettingsConnection instance and configures the instance (like calling nm_settings_connection_added()). This summary does not sound like a lot, but try to follow that code. The logic is all over the place. Instead, settings plugins should have a very simple API for adding, modifying, deleting, loading and reloading connections. All the plugin does is to return a NMSettingsStorage handle. The storage instance is a handle to identify a profile in storage (e.g. a particular file). The settings plugin is free to subtype NMSettingsStorage, but it's not necessary. There are no more events raised, and the settings plugin implements the small API in a straightforward manner. NMSettings now drives all of this. Even NMSettingsConnection has now very little concern about how it's tracked and delegates only to NMSettings. This should make settings plugins simpler. Currently settings plugins are so cumbersome to implement, that we avoid having them. It should not be like that and it should be easy, beneficial and lightweight to create a new settings plugin. Note also how the settings plugins no longer care about duplicate UUIDs. Duplicated UUIDs are a fact of life and NMSettings must handle them. No need to overly concern settings plugins with that. -- NMSettingsConnection is exposed directly on D-Bus (being a subtype of NMDBusObject) but it was also a GObject type provided by the settings plugin. Hence, it was not possible to migrate a profile from one plugin to another. However that would be useful when one profile does not support a connection type (like ifcfg-rh not supporting VPN). Currently such migration is not implemented except for migrating them to/from keyfile's run directory. The problem is that migrating profiles in general is complicated but in some cases it is important to do. For example checkpoint rollback should recreate the profile in the right settings plugin, not just add it to persistent storage. This is not yet properly implemented. -- Previously, both keyfile and ifcfg-rh plugin implemented in-memory (unsaved) profiles, while ifupdown plugin cannot handle them. That meant duplication of code and a ifupdown profile could not be modified or made unsaved. This is now unified and only keyfile plugin handles in-memory profiles (bgo #744711). Also, NMSettings is aware of such profiles and treats them specially. In particular, NMSettings drives the migration between persistent and non-persistent storage. Note that a settings plugins may create truly generated, in-memory profiles. The settings plugin is free to generate and persist the profiles in any way it wishes. But the concept of "unsaved" profiles is now something explicitly handled by keyfile plugin. Also, these "unsaved" keyfile profiles are persisted to file system too, to the /run directory. This is great for two reasons: first of all, all profiles from keyfile storage in fact have a backing file -- even the unsaved ones. It also means you can create "unsaved" profiles in /run and load them with `nmcli connection load`, meaning there is a file based API for creating unsaved profiles. The other advantage is that these profiles now survive restarting NetworkManager. It's paramount that restarting the daemon is as non-disruptive as possible. Persisting unsaved files to /run improves here significantly. -- In the past, NMSettingsConnection also implemented NMConnection interface. That was already changed a while ago and instead users call now nm_settings_connection_get_connection() to delegate to a NMSimpleConnection. What however still happened was that the NMConnection instance gets never swapped but instead the instance was modified with nm_connection_replace_settings_from_connection(), clear-secrets, etc. Change that and treat the NMConnection instance immutable. Instead of modifying it, reference/clone a new instance. This changes that previously when somebody wanted to keep a reference to an NMConnection, then the profile would be cloned. Now, it is supposed to be safe to reference the instance directly and everybody must ensure not to modify the instance. nmtst_connection_assert_unchanging() should help with that. The point is that the settings plugins may keep references to the NMConnection instance, and so does the NMSettingsConnection. We want to avoid cloning the instances as long as they are the same. Likewise, the device's applied connection can now also be referenced instead of cloning it. This is not yet done, and possibly there are further improvements possible. -- Also implement multiple keyfile directores /usr/lib, /etc, /run (rh #1674545, bgo #772414). It was always the case that multiple files could provide the same UUID (both in case of keyfile and ifcfg-rh). For keyfile plugin, if a profile in read-only storage in /usr/lib gets modified, then it gets actually stored in /etc (or /run, if the profile is unsaved). -- While at it, make /etc/network/interfaces profiles for ifupdown plugin reloadable. -- https://bugzilla.gnome.org/show_bug.cgi?id=772414 https://bugzilla.gnome.org/show_bug.cgi?id=744711 https://bugzilla.redhat.com/show_bug.cgi?id=1674545
2019-06-13 17:12:20 +02:00
#define NM_KEYFILE_GROUP_NMMETA ".nmmeta"
#define NM_KEYFILE_KEY_NMMETA_NM_GENERATED "nm-generated"
#define NM_KEYFILE_KEY_NMMETA_VOLATILE "volatile"
#define NM_KEYFILE_KEY_NMMETA_SHADOWED_STORAGE "shadowed-storage"
#define NM_KEYFILE_KEY_NMMETA_SHADOWED_OWNED "shadowed-owned"
settings: rework tracking settings connections and settings plugins Completely rework how settings plugin handle connections and how NMSettings tracks the list of connections. Previously, settings plugins would return objects of (a subtype of) type NMSettingsConnection. The NMSettingsConnection was tightly coupled with the settings plugin. That has a lot of downsides. Change that. When changing this basic relation how settings connections are tracked, everything falls appart. That's why this is a huge change. Also, since I have to largely rewrite the settings plugins, I also added support for multiple keyfile directories, handle in-memory connections only by keyfile plugin and (partly) use copy-on-write NMConnection instances. I don't want to spend effort rewriting large parts while preserving the old way, that anyway should change. E.g. while rewriting ifcfg-rh, I don't want to let it handle in-memory connections because that's not right long-term. -- If the settings plugins themself create subtypes of NMSettingsConnection instances, then a lot of knowledge about tracking connections moves to the plugins. Just try to follow the code what happend during nm_settings_add_connection(). Note how the logic is spread out: - nm_settings_add_connection() calls plugin's add_connection() - add_connection() creates a NMSettingsConnection subtype - the plugin has to know that it's called during add-connection and not emit NM_SETTINGS_PLUGIN_CONNECTION_ADDED signal - NMSettings calls claim_connection() which hocks up the new NMSettingsConnection instance and configures the instance (like calling nm_settings_connection_added()). This summary does not sound like a lot, but try to follow that code. The logic is all over the place. Instead, settings plugins should have a very simple API for adding, modifying, deleting, loading and reloading connections. All the plugin does is to return a NMSettingsStorage handle. The storage instance is a handle to identify a profile in storage (e.g. a particular file). The settings plugin is free to subtype NMSettingsStorage, but it's not necessary. There are no more events raised, and the settings plugin implements the small API in a straightforward manner. NMSettings now drives all of this. Even NMSettingsConnection has now very little concern about how it's tracked and delegates only to NMSettings. This should make settings plugins simpler. Currently settings plugins are so cumbersome to implement, that we avoid having them. It should not be like that and it should be easy, beneficial and lightweight to create a new settings plugin. Note also how the settings plugins no longer care about duplicate UUIDs. Duplicated UUIDs are a fact of life and NMSettings must handle them. No need to overly concern settings plugins with that. -- NMSettingsConnection is exposed directly on D-Bus (being a subtype of NMDBusObject) but it was also a GObject type provided by the settings plugin. Hence, it was not possible to migrate a profile from one plugin to another. However that would be useful when one profile does not support a connection type (like ifcfg-rh not supporting VPN). Currently such migration is not implemented except for migrating them to/from keyfile's run directory. The problem is that migrating profiles in general is complicated but in some cases it is important to do. For example checkpoint rollback should recreate the profile in the right settings plugin, not just add it to persistent storage. This is not yet properly implemented. -- Previously, both keyfile and ifcfg-rh plugin implemented in-memory (unsaved) profiles, while ifupdown plugin cannot handle them. That meant duplication of code and a ifupdown profile could not be modified or made unsaved. This is now unified and only keyfile plugin handles in-memory profiles (bgo #744711). Also, NMSettings is aware of such profiles and treats them specially. In particular, NMSettings drives the migration between persistent and non-persistent storage. Note that a settings plugins may create truly generated, in-memory profiles. The settings plugin is free to generate and persist the profiles in any way it wishes. But the concept of "unsaved" profiles is now something explicitly handled by keyfile plugin. Also, these "unsaved" keyfile profiles are persisted to file system too, to the /run directory. This is great for two reasons: first of all, all profiles from keyfile storage in fact have a backing file -- even the unsaved ones. It also means you can create "unsaved" profiles in /run and load them with `nmcli connection load`, meaning there is a file based API for creating unsaved profiles. The other advantage is that these profiles now survive restarting NetworkManager. It's paramount that restarting the daemon is as non-disruptive as possible. Persisting unsaved files to /run improves here significantly. -- In the past, NMSettingsConnection also implemented NMConnection interface. That was already changed a while ago and instead users call now nm_settings_connection_get_connection() to delegate to a NMSimpleConnection. What however still happened was that the NMConnection instance gets never swapped but instead the instance was modified with nm_connection_replace_settings_from_connection(), clear-secrets, etc. Change that and treat the NMConnection instance immutable. Instead of modifying it, reference/clone a new instance. This changes that previously when somebody wanted to keep a reference to an NMConnection, then the profile would be cloned. Now, it is supposed to be safe to reference the instance directly and everybody must ensure not to modify the instance. nmtst_connection_assert_unchanging() should help with that. The point is that the settings plugins may keep references to the NMConnection instance, and so does the NMSettingsConnection. We want to avoid cloning the instances as long as they are the same. Likewise, the device's applied connection can now also be referenced instead of cloning it. This is not yet done, and possibly there are further improvements possible. -- Also implement multiple keyfile directores /usr/lib, /etc, /run (rh #1674545, bgo #772414). It was always the case that multiple files could provide the same UUID (both in case of keyfile and ifcfg-rh). For keyfile plugin, if a profile in read-only storage in /usr/lib gets modified, then it gets actually stored in /etc (or /run, if the profile is unsaved). -- While at it, make /etc/network/interfaces profiles for ifupdown plugin reloadable. -- https://bugzilla.gnome.org/show_bug.cgi?id=772414 https://bugzilla.gnome.org/show_bug.cgi?id=744711 https://bugzilla.redhat.com/show_bug.cgi?id=1674545
2019-06-13 17:12:20 +02:00
#define NM_KEYFILE_PATH_NAME_LIB NMLIBDIR "/system-connections"
#define NM_KEYFILE_PATH_NAME_ETC_DEFAULT NMCONFDIR "/system-connections"
settings: rework tracking settings connections and settings plugins Completely rework how settings plugin handle connections and how NMSettings tracks the list of connections. Previously, settings plugins would return objects of (a subtype of) type NMSettingsConnection. The NMSettingsConnection was tightly coupled with the settings plugin. That has a lot of downsides. Change that. When changing this basic relation how settings connections are tracked, everything falls appart. That's why this is a huge change. Also, since I have to largely rewrite the settings plugins, I also added support for multiple keyfile directories, handle in-memory connections only by keyfile plugin and (partly) use copy-on-write NMConnection instances. I don't want to spend effort rewriting large parts while preserving the old way, that anyway should change. E.g. while rewriting ifcfg-rh, I don't want to let it handle in-memory connections because that's not right long-term. -- If the settings plugins themself create subtypes of NMSettingsConnection instances, then a lot of knowledge about tracking connections moves to the plugins. Just try to follow the code what happend during nm_settings_add_connection(). Note how the logic is spread out: - nm_settings_add_connection() calls plugin's add_connection() - add_connection() creates a NMSettingsConnection subtype - the plugin has to know that it's called during add-connection and not emit NM_SETTINGS_PLUGIN_CONNECTION_ADDED signal - NMSettings calls claim_connection() which hocks up the new NMSettingsConnection instance and configures the instance (like calling nm_settings_connection_added()). This summary does not sound like a lot, but try to follow that code. The logic is all over the place. Instead, settings plugins should have a very simple API for adding, modifying, deleting, loading and reloading connections. All the plugin does is to return a NMSettingsStorage handle. The storage instance is a handle to identify a profile in storage (e.g. a particular file). The settings plugin is free to subtype NMSettingsStorage, but it's not necessary. There are no more events raised, and the settings plugin implements the small API in a straightforward manner. NMSettings now drives all of this. Even NMSettingsConnection has now very little concern about how it's tracked and delegates only to NMSettings. This should make settings plugins simpler. Currently settings plugins are so cumbersome to implement, that we avoid having them. It should not be like that and it should be easy, beneficial and lightweight to create a new settings plugin. Note also how the settings plugins no longer care about duplicate UUIDs. Duplicated UUIDs are a fact of life and NMSettings must handle them. No need to overly concern settings plugins with that. -- NMSettingsConnection is exposed directly on D-Bus (being a subtype of NMDBusObject) but it was also a GObject type provided by the settings plugin. Hence, it was not possible to migrate a profile from one plugin to another. However that would be useful when one profile does not support a connection type (like ifcfg-rh not supporting VPN). Currently such migration is not implemented except for migrating them to/from keyfile's run directory. The problem is that migrating profiles in general is complicated but in some cases it is important to do. For example checkpoint rollback should recreate the profile in the right settings plugin, not just add it to persistent storage. This is not yet properly implemented. -- Previously, both keyfile and ifcfg-rh plugin implemented in-memory (unsaved) profiles, while ifupdown plugin cannot handle them. That meant duplication of code and a ifupdown profile could not be modified or made unsaved. This is now unified and only keyfile plugin handles in-memory profiles (bgo #744711). Also, NMSettings is aware of such profiles and treats them specially. In particular, NMSettings drives the migration between persistent and non-persistent storage. Note that a settings plugins may create truly generated, in-memory profiles. The settings plugin is free to generate and persist the profiles in any way it wishes. But the concept of "unsaved" profiles is now something explicitly handled by keyfile plugin. Also, these "unsaved" keyfile profiles are persisted to file system too, to the /run directory. This is great for two reasons: first of all, all profiles from keyfile storage in fact have a backing file -- even the unsaved ones. It also means you can create "unsaved" profiles in /run and load them with `nmcli connection load`, meaning there is a file based API for creating unsaved profiles. The other advantage is that these profiles now survive restarting NetworkManager. It's paramount that restarting the daemon is as non-disruptive as possible. Persisting unsaved files to /run improves here significantly. -- In the past, NMSettingsConnection also implemented NMConnection interface. That was already changed a while ago and instead users call now nm_settings_connection_get_connection() to delegate to a NMSimpleConnection. What however still happened was that the NMConnection instance gets never swapped but instead the instance was modified with nm_connection_replace_settings_from_connection(), clear-secrets, etc. Change that and treat the NMConnection instance immutable. Instead of modifying it, reference/clone a new instance. This changes that previously when somebody wanted to keep a reference to an NMConnection, then the profile would be cloned. Now, it is supposed to be safe to reference the instance directly and everybody must ensure not to modify the instance. nmtst_connection_assert_unchanging() should help with that. The point is that the settings plugins may keep references to the NMConnection instance, and so does the NMSettingsConnection. We want to avoid cloning the instances as long as they are the same. Likewise, the device's applied connection can now also be referenced instead of cloning it. This is not yet done, and possibly there are further improvements possible. -- Also implement multiple keyfile directores /usr/lib, /etc, /run (rh #1674545, bgo #772414). It was always the case that multiple files could provide the same UUID (both in case of keyfile and ifcfg-rh). For keyfile plugin, if a profile in read-only storage in /usr/lib gets modified, then it gets actually stored in /etc (or /run, if the profile is unsaved). -- While at it, make /etc/network/interfaces profiles for ifupdown plugin reloadable. -- https://bugzilla.gnome.org/show_bug.cgi?id=772414 https://bugzilla.gnome.org/show_bug.cgi?id=744711 https://bugzilla.redhat.com/show_bug.cgi?id=1674545
2019-06-13 17:12:20 +02:00
#define NM_KEYFILE_PATH_NAME_RUN NMRUNDIR "/system-connections"
#define NM_KEYFILE_PATH_SUFFIX_NMCONNECTION ".nmconnection"
#define NM_KEYFILE_PATH_SUFFIX_NMMETA ".nmmeta"
keyfile: add helper functions to record loaded UUID files This code will be used later. We want to remember which keyfiles are currently loaded (or hidden). With the addition or multiple keyfile directories (soon), there are two cases where this matters: - if there are multiple keyfiles which reference the same UUID, we can only load one of them. That is already a problem today with only one keyfile directory, where multiple files can reference the same UUID. The implementation will pick the file based on priorities (like the file modification date). However, the user may call explicitly call `nmcli connection load`. In that case, we cannot reload all files to find out whether the to be loaded file is hidden according to the defined priorities. We cannot do that, because we must not make decisions based on files on disk, which we are not told to reload. So, during a `nmcli connection load` we must look at unrelated files, to determine how to load the file. Instead, we do allow the user to load any file, even if it would be shadowed by other files. When we do that, we may want to persist which file is currently loaded, so that a service restart and a `nmcli connection reload` does not undo the load again. This can be later later be solved by writing a symlink "/var/run/NetworkManager/system-connections/.loaded-$UUID.nmkeyfile" which targets the currently active file. - if a profile was loaded from read-only persistant storage, the user may still delete the profile. We also need to remember the deletion of the file. That will be achieved by symlinking "/dev/null" as "/etc/NetworkManager/system-connections/.loaded-$UUID.nmkeyfile". Add helper functions to read and write these symlinks.
2018-10-01 00:42:12 +02:00
#define NM_KEYFILE_PATH_NMMETA_SYMLINK_NULL "/dev/null"
keyfile: add helper functions to record loaded UUID files This code will be used later. We want to remember which keyfiles are currently loaded (or hidden). With the addition or multiple keyfile directories (soon), there are two cases where this matters: - if there are multiple keyfiles which reference the same UUID, we can only load one of them. That is already a problem today with only one keyfile directory, where multiple files can reference the same UUID. The implementation will pick the file based on priorities (like the file modification date). However, the user may call explicitly call `nmcli connection load`. In that case, we cannot reload all files to find out whether the to be loaded file is hidden according to the defined priorities. We cannot do that, because we must not make decisions based on files on disk, which we are not told to reload. So, during a `nmcli connection load` we must look at unrelated files, to determine how to load the file. Instead, we do allow the user to load any file, even if it would be shadowed by other files. When we do that, we may want to persist which file is currently loaded, so that a service restart and a `nmcli connection reload` does not undo the load again. This can be later later be solved by writing a symlink "/var/run/NetworkManager/system-connections/.loaded-$UUID.nmkeyfile" which targets the currently active file. - if a profile was loaded from read-only persistant storage, the user may still delete the profile. We also need to remember the deletion of the file. That will be achieved by symlinking "/dev/null" as "/etc/NetworkManager/system-connections/.loaded-$UUID.nmkeyfile". Add helper functions to read and write these symlinks.
2018-10-01 00:42:12 +02:00
gboolean nm_keyfile_utils_ignore_filename (const char *filename, gboolean require_extension);
char *nm_keyfile_utils_create_filename (const char *filename, gboolean with_extension);
#endif /* __NM_KEYFILE_INTERNAL_H__ */