fdo-mirrors/NetworkManager
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git synced 2026-05-24 09:58:14 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions
NetworkManager/src/settings/nm-agent-manager.h

91 lines
4.5 KiB
C
Raw Normal View History

agent: add agent manager and minimal agent class
2010-12-10 12:38:19 -06:00
/* -*- Mode: C; tab-width: 4; indent-tabs-mode: t; c-basic-offset: 4 -*- */
/* NetworkManager -- Network link manager
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License along
* with this program; if not, write to the Free Software Foundation, Inc.,
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
*
agents: filter agents by UID for user-requested connections When a user makes an explicit request for secrets via GetSecrets or activates a device, don't ask other users' agents for secrets. Restrict secrets request to agents owned by the user that made the initial activate or GetSecrets request. Automatic activations still request secrets from any available agent.
2011-01-26 18:36:08 -06:00
* Copyright (C) 2010 - 2011 Red Hat, Inc.
agent: add agent manager and minimal agent class
2010-12-10 12:38:19 -06:00
*/
all: fix up multiple-include-guard defines Previously, src/nm-ip4-config.h, libnm/nm-ip4-config.h, and libnm-glib/nm-ip4-config.h all used "NM_IP4_CONFIG_H" as an include guard, which meant that nm-test-utils.h could not tell which of them was being included (and so, eg, if you tried to include nm-ip4-config.h in a libnm test, it would fail to compile because nm-test-utils.h was referring to symbols in src/nm-ip4-config.h). Fix this by changing the include guards in the non-API-stable parts of the tree: - libnm-glib/nm-ip4-config.h remains NM_IP4_CONFIG_H - libnm/nm-ip4-config.h now uses __NM_IP4_CONFIG_H__ - src/nm-ip4-config.h now uses __NETWORKMANAGER_IP4_CONFIG_H__ And likewise for all other headers. The two non-"nm"-prefixed headers, libnm/NetworkManager.h and src/NetworkManagerUtils.h are now __NETWORKMANAGER_H__ and __NETWORKMANAGER_UTILS_H__ respectively, which, while not entirely consistent with the general scheme, do still mostly make sense in isolation.
2014-08-13 14:10:11 -04:00
#ifndef __NETWORKMANAGER_AGENT_MANAGER_H__
#define __NETWORKMANAGER_AGENT_MANAGER_H__
agent: add agent manager and minimal agent class
2010-12-10 12:38:19 -06:00
all: move NM_AUTH_PERMISSION_* defines to "nm-common-macros.h" header
2016-06-01 12:31:36 +02:00
#include "nm-connection.h"
core: add an NMExportedObject base class Add NMExportedObject, make it the base class of all D-Bus-exported types, and move the nm-properties-changed-signal logic into it. (Also, make NMSettings use the same properties-changed code as everything else, which it was not previously doing, presumably for historical reasons). (This is mostly just shuffling code around at this point, but NMExportedObject will be more important in the gdbus port, since gdbus-codegen doesn't do a very good job of supporting objects that export multiple interfaces [as each NMDevice subclass does, for example], so we will need more glue/helper code in NMExportedObject then.)
2015-04-13 13:31:42 -04:00
#include "nm-exported-object.h"
core: connections failed due to missing secrets are re-tried when an secret agent registers (rh #706204) Use case: A user has an auto-activatable connection with secrets in a keyring. While booting NM starts and tries to activate the connection, but it fails because of missing secrets. Then the user logs in, but the connection is marked as invalid and is not tried again. This commit solves the issue by removing invalid flag and activating the connection when a secret agent registers. Signed-off-by: Jiří Klimeš <jklimes@redhat.com>
2011-06-28 15:48:12 +02:00
#include "nm-secret-agent.h"
core: simplify secrets handling during activation Instead of a bizare mechanism of signals back to the manager object that used to be required because of the user/system settings split, let each place that needs secrets request those secrets itself. This flattens the secrets request process a ton and the code flow significantly. Previously the get secrets flow was something like this: nm_act_request_get_secrets () nm_secrets_provider_interface_get_secrets () emits manager-get-secrets signal provider_get_secerts () system_get_secrets () system_get_secrets_idle_cb () nm_sysconfig_connection_get_secrets () system_get_secrets_reply_cb () nm_secrets_provider_interface_get_secrets_result () signal failure or success now instead we do something like this: nm_agent_manager_get_secrets () nm_agent_manager_get_secrets () request_start_secrets () nm_sysconfig_connection_get_secrets () return failure or success to callback
2010-12-13 13:11:51 -06:00
agent: add agent manager and minimal agent class
2010-12-10 12:38:19 -06:00
#define NM_TYPE_AGENT_MANAGER (nm_agent_manager_get_type ())
#define NM_AGENT_MANAGER(obj) (G_TYPE_CHECK_INSTANCE_CAST ((obj), NM_TYPE_AGENT_MANAGER, NMAgentManager))
#define NM_AGENT_MANAGER_CLASS(klass) (G_TYPE_CHECK_CLASS_CAST ((klass), NM_TYPE_AGENT_MANAGER, NMAgentManagerClass))
#define NM_IS_AGENT_MANAGER(obj) (G_TYPE_CHECK_INSTANCE_TYPE ((obj), NM_TYPE_AGENT_MANAGER))
core: fix NM_IS_*_CLASS(klass) macros The argument is 'klass' not 'obj'.
2012-07-27 13:15:54 +02:00
#define NM_IS_AGENT_MANAGER_CLASS(klass) (G_TYPE_CHECK_CLASS_TYPE ((klass), NM_TYPE_AGENT_MANAGER))
agent: add agent manager and minimal agent class
2010-12-10 12:38:19 -06:00
#define NM_AGENT_MANAGER_GET_CLASS(obj) (G_TYPE_INSTANCE_GET_CLASS ((obj), NM_TYPE_AGENT_MANAGER, NMAgentManagerClass))
core: use #define for "agent-registered" signal name
2017-11-24 18:17:26 +01:00
#define NM_AGENT_MANAGER_AGENT_REGISTERED "agent-registered"
settings: refactor call_id type of async functions for NMAgentManager, NMSettingsConnection and NMActRequest Instead of having the call_id of type guint32, make it an (opaque) pointer type. This has the advantage of strong typing and avoids the possiblity of reusing an invalid integer (or overflow of the call-id counter). OTOH, it has the disadvantage, that after a call_id is disposed, it might be reused for future invocations (because malloc might reuse the memory). In fact, it is always an error to use a call_id that is already completed. This commit also adds assertions to the cancel() calls that the provided call_id is a pending call. Hence, such a bug will be uncovered by assertions (that only might not tigger in certain unlikely cases where a call-id got reused). Note that for NMAgentManager, save_secrets() and delete_secrets() both returned a call_id. But they didn't also provide a callback when the operation completes. So the user trying to cancel such a call, cannot know whether the operation is still in process and he cannot avoid triggering an assertion. Fix that by not returning a call-id for these operations. No caller cared about it anyway. For NMSettingsConnection, also track the internally scheduled requests for so that we can cancel them on dispose.
2015-09-02 22:43:04 +02:00
typedef struct _NMAgentManagerCallId *NMAgentManagerCallId;
core: refactor private data in "src" - use _NM_GET_PRIVATE() and _NM_GET_PRIVATE_PTR() everywhere. - reorder statements, to have GObject related functions (init, dispose, constructed) at the bottom of each file and in a consistent order w.r.t. each other. - unify whitespaces in signal and properties declarations. - use NM_GOBJECT_PROPERTIES_DEFINE() and _notify() - drop unused signal slots in class structures - drop unused header files for device factories
2016-09-29 13:49:01 +02:00
typedef struct _NMAgentManagerClass NMAgentManagerClass;
agent: add agent manager and minimal agent class
2010-12-10 12:38:19 -06:00
GType nm_agent_manager_get_type (void);
core: move secrets handling to NMSettingsConnection It's the thing that owns the secrets anyway, and it simplifies things to have the secrets handling there instead of half in NMActRequest and half in NMManager. It also means we can get rid of the ugly signals that NMSettingsConnection had to emit to get agent's secrets, and we can consolidate the requests for the persistent secrets that the NMSettingsConnection owned into NMSettingsConnection itself instead of also in NMAgentManager. Since the NMActRequest and the NMVPNConnection classes already tracked the underlying NMSettingsConnection representing the activation, its trivial to just have them ask the NMSettingsConnection for secrets instead of talking to the NMAgentManager. Thus, only the NMSettingsConnection now has to know about the agent manager, and it presents a cleaner interface to other objects further up the chain, instead of having bits of the secrets request splattered around the activation request, the VPN connection, the NMManager, etc.
2011-01-27 10:41:02 -06:00
NMAgentManager *nm_agent_manager_get (void);
core: simplify secrets handling during activation Instead of a bizare mechanism of signals back to the manager object that used to be required because of the user/system settings split, let each place that needs secrets request those secrets itself. This flattens the secrets request process a ton and the code flow significantly. Previously the get secrets flow was something like this: nm_act_request_get_secrets () nm_secrets_provider_interface_get_secrets () emits manager-get-secrets signal provider_get_secerts () system_get_secrets () system_get_secrets_idle_cb () nm_sysconfig_connection_get_secrets () system_get_secrets_reply_cb () nm_secrets_provider_interface_get_secrets_result () signal failure or success now instead we do something like this: nm_agent_manager_get_secrets () nm_agent_manager_get_secrets () request_start_secrets () nm_sysconfig_connection_get_secrets () return failure or success to callback
2010-12-13 13:11:51 -06:00
core: fix race of blocking autoconnect for no-secrets when a new secret-agent registers When activation of the connection fails with no-secrets, we block autoconnect due to that. However, NMPolicy also unblocks such autoconnect, whenever a new secret-agent registers. The reason is obviously, that the new secret-agent might be able to provide the previously missing secrets. However, there is a race between - making the secret request, failing activation and blocking autoconnect - new secret-agent registers If the secret-agent registers after making the request, but before we block autoconnect, then autoconnect stays blocked. [1511468634.5759] device (wlp4s0): state change: config -> need-auth (reason 'none', sys-iface-state: 'managed') [1511468634.5772] device (wlp4s0): No agents were available for this request. [1511468638.4082] agent-manager: req[0x55ea7e58a5d0, :1.32/org.kde.plasma.networkmanagement/1000]: agent registered [1511468638.4082] policy: re-enabling autoconnect for all connections with failed secrets [1511468664.6280] device (wlp4s0): state change: need-auth -> failed (reason 'no-secrets', sys-iface-state: 'managed') [1511468664.6287] policy: connection 'tuxmobil' now blocked from autoconnect due to no secrets Note the long timing between making the secret request and the activation failure. This race already existed before, but now with WPS push-button method enabled by default, the duraction of the activation is much longer and the race is easy to hit. https://bugzilla.gnome.org/show_bug.cgi?id=790571
2017-11-27 09:33:32 +01:00
guint64 nm_agent_manager_get_agent_version_id (NMAgentManager *self);
settings: ensure an agent is authorized before overwriting system-owned secrets If the agent returns system-owned secrets, like when activating a new connection which was created with no secrets, make sure the agent is authorized to modify network settings before saving or using the new secrets.
2011-02-02 12:17:58 -06:00
/* If no agent fulfilled the secrets request, agent_dbus_owner will be NULL */
core: simplify secrets handling during activation Instead of a bizare mechanism of signals back to the manager object that used to be required because of the user/system settings split, let each place that needs secrets request those secrets itself. This flattens the secrets request process a ton and the code flow significantly. Previously the get secrets flow was something like this: nm_act_request_get_secrets () nm_secrets_provider_interface_get_secrets () emits manager-get-secrets signal provider_get_secerts () system_get_secrets () system_get_secrets_idle_cb () nm_sysconfig_connection_get_secrets () system_get_secrets_reply_cb () nm_secrets_provider_interface_get_secrets_result () signal failure or success now instead we do something like this: nm_agent_manager_get_secrets () nm_agent_manager_get_secrets () request_start_secrets () nm_sysconfig_connection_get_secrets () return failure or success to callback
2010-12-13 13:11:51 -06:00
typedef void (*NMAgentSecretsResultFunc) (NMAgentManager *manager,
settings: refactor call_id type of async functions for NMAgentManager, NMSettingsConnection and NMActRequest Instead of having the call_id of type guint32, make it an (opaque) pointer type. This has the advantage of strong typing and avoids the possiblity of reusing an invalid integer (or overflow of the call-id counter). OTOH, it has the disadvantage, that after a call_id is disposed, it might be reused for future invocations (because malloc might reuse the memory). In fact, it is always an error to use a call_id that is already completed. This commit also adds assertions to the cancel() calls that the provided call_id is a pending call. Hence, such a bug will be uncovered by assertions (that only might not tigger in certain unlikely cases where a call-id got reused). Note that for NMAgentManager, save_secrets() and delete_secrets() both returned a call_id. But they didn't also provide a callback when the operation completes. So the user trying to cancel such a call, cannot know whether the operation is still in process and he cannot avoid triggering an assertion. Fix that by not returning a call-id for these operations. No caller cared about it anyway. For NMSettingsConnection, also track the internally scheduled requests for so that we can cancel them on dispose.
2015-09-02 22:43:04 +02:00
NMAgentManagerCallId call_id,
settings: ensure an agent is authorized before overwriting system-owned secrets If the agent returns system-owned secrets, like when activating a new connection which was created with no secrets, make sure the agent is authorized to modify network settings before saving or using the new secrets.
2011-02-02 12:17:58 -06:00
const char *agent_dbus_owner,
settings: return username of agent providing secrets Mainly for VPN connections to grab the default username from, like 0.8 did when the applet provided the username to NM for user connections.
2011-03-31 18:39:09 -05:00
const char *agent_uname,
agents: send system-owned secrets to the agent if it has 'modify' permission If we can authenticate the agent for 'modify' permission, then send any existing system secrets to it as the user has permission to change those secrets. This means the agent doesn't have to call GetSecrets() itself, which means simpler code on the agent side for a slight LoC hit in NM itself. This also moves the permissions checking into the NMAgentManager to check each agent, which is sub-optimal since now the agent manager has to do PolicyKit stuff, but hey that's life. Agents need secrets, and we do need to authenticate every agent before we send secrets to them, and the NMSettingsConnection doesn't know about individual agents at all.
2011-02-02 16:19:15 -06:00
gboolean agent_has_modify,
agent: pass setting name back in secrets callback
2011-01-26 13:32:25 -06:00
const char *setting_name,
include: drop nm-settings-flags.h, move NMSecretAgentGetSecretsFlags For some reason, the flags used by o.fd.NM.SecretAgent.GetSecrets were defined as both NMSecretAgentGetSecretsFlags in libnm{,-glib}/nm-secret-agent.h, and then separately as NMSettingsGetSecretsFlags in include/nm-settings-flags.h. (NMSettingsGetSecretsFlags also had an additional internal-use-only value, but that was added later after the duplication already existed.) Fix this by moving NMSecretAgentGetSecretsFlags from libnm to nm-dbus-interface.h, adding the internal-use-only value to it as well, updating the core code to use that, and then removing nm-settings-flags.h.
2014-07-07 10:11:46 -04:00
NMSecretAgentGetSecretsFlags flags,
settings: port to gdbus
2015-04-15 14:53:30 -04:00
GVariant *secrets,
core: simplify secrets handling during activation Instead of a bizare mechanism of signals back to the manager object that used to be required because of the user/system settings split, let each place that needs secrets request those secrets itself. This flattens the secrets request process a ton and the code flow significantly. Previously the get secrets flow was something like this: nm_act_request_get_secrets () nm_secrets_provider_interface_get_secrets () emits manager-get-secrets signal provider_get_secerts () system_get_secrets () system_get_secrets_idle_cb () nm_sysconfig_connection_get_secrets () system_get_secrets_reply_cb () nm_secrets_provider_interface_get_secrets_result () signal failure or success now instead we do something like this: nm_agent_manager_get_secrets () nm_agent_manager_get_secrets () request_start_secrets () nm_sysconfig_connection_get_secrets () return failure or success to callback
2010-12-13 13:11:51 -06:00
GError *error,
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
gpointer user_data);
core: simplify secrets handling during activation Instead of a bizare mechanism of signals back to the manager object that used to be required because of the user/system settings split, let each place that needs secrets request those secrets itself. This flattens the secrets request process a ton and the code flow significantly. Previously the get secrets flow was something like this: nm_act_request_get_secrets () nm_secrets_provider_interface_get_secrets () emits manager-get-secrets signal provider_get_secerts () system_get_secrets () system_get_secrets_idle_cb () nm_sysconfig_connection_get_secrets () system_get_secrets_reply_cb () nm_secrets_provider_interface_get_secrets_result () signal failure or success now instead we do something like this: nm_agent_manager_get_secrets () nm_agent_manager_get_secrets () request_start_secrets () nm_sysconfig_connection_get_secrets () return failure or success to callback
2010-12-13 13:11:51 -06:00
settings: refactor call_id type of async functions for NMAgentManager, NMSettingsConnection and NMActRequest Instead of having the call_id of type guint32, make it an (opaque) pointer type. This has the advantage of strong typing and avoids the possiblity of reusing an invalid integer (or overflow of the call-id counter). OTOH, it has the disadvantage, that after a call_id is disposed, it might be reused for future invocations (because malloc might reuse the memory). In fact, it is always an error to use a call_id that is already completed. This commit also adds assertions to the cancel() calls that the provided call_id is a pending call. Hence, such a bug will be uncovered by assertions (that only might not tigger in certain unlikely cases where a call-id got reused). Note that for NMAgentManager, save_secrets() and delete_secrets() both returned a call_id. But they didn't also provide a callback when the operation completes. So the user trying to cancel such a call, cannot know whether the operation is still in process and he cannot avoid triggering an assertion. Fix that by not returning a call-id for these operations. No caller cared about it anyway. For NMSettingsConnection, also track the internally scheduled requests for so that we can cancel them on dispose.
2015-09-02 22:43:04 +02:00
NMAgentManagerCallId nm_agent_manager_get_secrets (NMAgentManager *manager,
secrets: make agent-manager independent from NMSettingsConnection NMSecretAgent (and in turn NMAgentManager) used the @connection argument both for the connection data, but also for the connection path. Detangle these, and accept the path separate from the connection. This makes NMSecretAgent and NMAgentManager truly operate on a plain NMConnection, without the non-obvious requirement, that the path of the connection must be set.
2015-09-07 16:12:04 +02:00
const char *path,
settings: refactor call_id type of async functions for NMAgentManager, NMSettingsConnection and NMActRequest Instead of having the call_id of type guint32, make it an (opaque) pointer type. This has the advantage of strong typing and avoids the possiblity of reusing an invalid integer (or overflow of the call-id counter). OTOH, it has the disadvantage, that after a call_id is disposed, it might be reused for future invocations (because malloc might reuse the memory). In fact, it is always an error to use a call_id that is already completed. This commit also adds assertions to the cancel() calls that the provided call_id is a pending call. Hence, such a bug will be uncovered by assertions (that only might not tigger in certain unlikely cases where a call-id got reused). Note that for NMAgentManager, save_secrets() and delete_secrets() both returned a call_id. But they didn't also provide a callback when the operation completes. So the user trying to cancel such a call, cannot know whether the operation is still in process and he cannot avoid triggering an assertion. Fix that by not returning a call-id for these operations. No caller cared about it anyway. For NMSettingsConnection, also track the internally scheduled requests for so that we can cancel them on dispose.
2015-09-02 22:43:04 +02:00
NMConnection *connection,
NMAuthSubject *subject,
GVariant *existing_secrets,
const char *setting_name,
NMSecretAgentGetSecretsFlags flags,
core/vpn: mark secret hints as const
2017-11-17 22:34:02 +01:00
const char *const*hints,
settings: refactor call_id type of async functions for NMAgentManager, NMSettingsConnection and NMActRequest Instead of having the call_id of type guint32, make it an (opaque) pointer type. This has the advantage of strong typing and avoids the possiblity of reusing an invalid integer (or overflow of the call-id counter). OTOH, it has the disadvantage, that after a call_id is disposed, it might be reused for future invocations (because malloc might reuse the memory). In fact, it is always an error to use a call_id that is already completed. This commit also adds assertions to the cancel() calls that the provided call_id is a pending call. Hence, such a bug will be uncovered by assertions (that only might not tigger in certain unlikely cases where a call-id got reused). Note that for NMAgentManager, save_secrets() and delete_secrets() both returned a call_id. But they didn't also provide a callback when the operation completes. So the user trying to cancel such a call, cannot know whether the operation is still in process and he cannot avoid triggering an assertion. Fix that by not returning a call-id for these operations. No caller cared about it anyway. For NMSettingsConnection, also track the internally scheduled requests for so that we can cancel them on dispose.
2015-09-02 22:43:04 +02:00
NMAgentSecretsResultFunc callback,
core: separate active and applied connection Clone the connection upon activation. This makes it safe for the user to modify the original connection while it is activated. This involves several changes: - NMActiveConnection gets @settings_connection and @applied_connection. To support add-and-activate, we constructing a NMActiveConnection with no connection set. Previously, we would set the "connection" field to a temporary NMConnection. Now NMManager piggybacks this temporary connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE). - get rid of the functions nm_active_connection_get_connection_type() and nm_active_connection_get_connection_uuid(). From their names it is unclear whether this returns the settings or applied connection. The (few) callers should figure that out themselves. - rename nm_active_connection_get_id() to nm_active_connection_get_settings_connection_id(). This function is only used internally for logging. - dispatcher calls now get two connections as well. The applied-connection is used for the connection data, while the settings-connection is used for the connection path. - needs special handling for properties that apply immediately when changed (nm_device_reapply_settings_immediately()). Co-Authored-By: Thomas Haller <thaller@redhat.com> https://bugzilla.gnome.org/show_bug.cgi?id=724041
2015-07-14 16:53:24 +02:00
gpointer callback_data);
core: simplify secrets handling during activation Instead of a bizare mechanism of signals back to the manager object that used to be required because of the user/system settings split, let each place that needs secrets request those secrets itself. This flattens the secrets request process a ton and the code flow significantly. Previously the get secrets flow was something like this: nm_act_request_get_secrets () nm_secrets_provider_interface_get_secrets () emits manager-get-secrets signal provider_get_secerts () system_get_secrets () system_get_secrets_idle_cb () nm_sysconfig_connection_get_secrets () system_get_secrets_reply_cb () nm_secrets_provider_interface_get_secrets_result () signal failure or success now instead we do something like this: nm_agent_manager_get_secrets () nm_agent_manager_get_secrets () request_start_secrets () nm_sysconfig_connection_get_secrets () return failure or success to callback
2010-12-13 13:11:51 -06:00
void nm_agent_manager_cancel_secrets (NMAgentManager *manager,
settings: refactor call_id type of async functions for NMAgentManager, NMSettingsConnection and NMActRequest Instead of having the call_id of type guint32, make it an (opaque) pointer type. This has the advantage of strong typing and avoids the possiblity of reusing an invalid integer (or overflow of the call-id counter). OTOH, it has the disadvantage, that after a call_id is disposed, it might be reused for future invocations (because malloc might reuse the memory). In fact, it is always an error to use a call_id that is already completed. This commit also adds assertions to the cancel() calls that the provided call_id is a pending call. Hence, such a bug will be uncovered by assertions (that only might not tigger in certain unlikely cases where a call-id got reused). Note that for NMAgentManager, save_secrets() and delete_secrets() both returned a call_id. But they didn't also provide a callback when the operation completes. So the user trying to cancel such a call, cannot know whether the operation is still in process and he cannot avoid triggering an assertion. Fix that by not returning a call-id for these operations. No caller cared about it anyway. For NMSettingsConnection, also track the internally scheduled requests for so that we can cancel them on dispose.
2015-09-02 22:43:04 +02:00
NMAgentManagerCallId request_id);
agent: add agent manager and minimal agent class
2010-12-10 12:38:19 -06:00
settings: refactor call_id type of async functions for NMAgentManager, NMSettingsConnection and NMActRequest Instead of having the call_id of type guint32, make it an (opaque) pointer type. This has the advantage of strong typing and avoids the possiblity of reusing an invalid integer (or overflow of the call-id counter). OTOH, it has the disadvantage, that after a call_id is disposed, it might be reused for future invocations (because malloc might reuse the memory). In fact, it is always an error to use a call_id that is already completed. This commit also adds assertions to the cancel() calls that the provided call_id is a pending call. Hence, such a bug will be uncovered by assertions (that only might not tigger in certain unlikely cases where a call-id got reused). Note that for NMAgentManager, save_secrets() and delete_secrets() both returned a call_id. But they didn't also provide a callback when the operation completes. So the user trying to cancel such a call, cannot know whether the operation is still in process and he cannot avoid triggering an assertion. Fix that by not returning a call-id for these operations. No caller cared about it anyway. For NMSettingsConnection, also track the internally scheduled requests for so that we can cancel them on dispose.
2015-09-02 22:43:04 +02:00
void nm_agent_manager_save_secrets (NMAgentManager *manager,
secrets: make agent-manager independent from NMSettingsConnection NMSecretAgent (and in turn NMAgentManager) used the @connection argument both for the connection data, but also for the connection path. Detangle these, and accept the path separate from the connection. This makes NMSecretAgent and NMAgentManager truly operate on a plain NMConnection, without the non-obvious requirement, that the path of the connection must be set.
2015-09-07 16:12:04 +02:00
const char *path,
settings: refactor call_id type of async functions for NMAgentManager, NMSettingsConnection and NMActRequest Instead of having the call_id of type guint32, make it an (opaque) pointer type. This has the advantage of strong typing and avoids the possiblity of reusing an invalid integer (or overflow of the call-id counter). OTOH, it has the disadvantage, that after a call_id is disposed, it might be reused for future invocations (because malloc might reuse the memory). In fact, it is always an error to use a call_id that is already completed. This commit also adds assertions to the cancel() calls that the provided call_id is a pending call. Hence, such a bug will be uncovered by assertions (that only might not tigger in certain unlikely cases where a call-id got reused). Note that for NMAgentManager, save_secrets() and delete_secrets() both returned a call_id. But they didn't also provide a callback when the operation completes. So the user trying to cancel such a call, cannot know whether the operation is still in process and he cannot avoid triggering an assertion. Fix that by not returning a call-id for these operations. No caller cared about it anyway. For NMSettingsConnection, also track the internally scheduled requests for so that we can cancel them on dispose.
2015-09-02 22:43:04 +02:00
NMConnection *connection,
NMAuthSubject *subject);
settings: implement saving secrets to agents on Update()
2011-01-31 23:10:33 -06:00
settings: refactor call_id type of async functions for NMAgentManager, NMSettingsConnection and NMActRequest Instead of having the call_id of type guint32, make it an (opaque) pointer type. This has the advantage of strong typing and avoids the possiblity of reusing an invalid integer (or overflow of the call-id counter). OTOH, it has the disadvantage, that after a call_id is disposed, it might be reused for future invocations (because malloc might reuse the memory). In fact, it is always an error to use a call_id that is already completed. This commit also adds assertions to the cancel() calls that the provided call_id is a pending call. Hence, such a bug will be uncovered by assertions (that only might not tigger in certain unlikely cases where a call-id got reused). Note that for NMAgentManager, save_secrets() and delete_secrets() both returned a call_id. But they didn't also provide a callback when the operation completes. So the user trying to cancel such a call, cannot know whether the operation is still in process and he cannot avoid triggering an assertion. Fix that by not returning a call-id for these operations. No caller cared about it anyway. For NMSettingsConnection, also track the internally scheduled requests for so that we can cancel them on dispose.
2015-09-02 22:43:04 +02:00
void nm_agent_manager_delete_secrets (NMAgentManager *manager,
secrets: make agent-manager independent from NMSettingsConnection NMSecretAgent (and in turn NMAgentManager) used the @connection argument both for the connection data, but also for the connection path. Detangle these, and accept the path separate from the connection. This makes NMSecretAgent and NMAgentManager truly operate on a plain NMConnection, without the non-obvious requirement, that the path of the connection must be set.
2015-09-07 16:12:04 +02:00
const char *path,
settings: refactor call_id type of async functions for NMAgentManager, NMSettingsConnection and NMActRequest Instead of having the call_id of type guint32, make it an (opaque) pointer type. This has the advantage of strong typing and avoids the possiblity of reusing an invalid integer (or overflow of the call-id counter). OTOH, it has the disadvantage, that after a call_id is disposed, it might be reused for future invocations (because malloc might reuse the memory). In fact, it is always an error to use a call_id that is already completed. This commit also adds assertions to the cancel() calls that the provided call_id is a pending call. Hence, such a bug will be uncovered by assertions (that only might not tigger in certain unlikely cases where a call-id got reused). Note that for NMAgentManager, save_secrets() and delete_secrets() both returned a call_id. But they didn't also provide a callback when the operation completes. So the user trying to cancel such a call, cannot know whether the operation is still in process and he cannot avoid triggering an assertion. Fix that by not returning a call-id for these operations. No caller cared about it anyway. For NMSettingsConnection, also track the internally scheduled requests for so that we can cancel them on dispose.
2015-09-02 22:43:04 +02:00
NMConnection *connection);
settings: implement deleting secrets from agents when connection is deleted
2011-01-31 23:33:46 -06:00
agents: add nm_agent_manager_get_agent_by_user() Return any registered agent for a given username.
2011-07-01 14:36:01 -05:00
NMSecretAgent *nm_agent_manager_get_agent_by_user (NMAgentManager *manager,
const char *username);
vpn: handle interactive plugin secrets requests If all agents can handle VPN hints, then we'll try to use ConnectInteractive() to let the VPN plugin ask for secrets interactively via the SecretsRequired signal. These hints are then passed to agents during the connection process if the plugin needs more secrets or different secrets, and when the new secrets are returned, they are passed back to the VPN plugin. If at least one agent does not have the VPN hints capability, we can't use ConnectInteractive(), but fall back to the old Connect call, because that agent won't be able to send the hints to the VPN plugin's authentication dialog, and thus we won't get back the secrets the VPN plugin is looking for. So, for interactive secrets to work correctly, you need: 1) A VPN plugin updated for interactive secrets requests 2) NM updated for interactive secrets requests 3) all agents to set the VPN_HINTS capability when registering with NetworkManager and to pass hints along to the VPN authentication dialog 4) a VPN authentication dialog updated to look for hints and only return secrets corresponding to the hints requested by the plugin
2013-06-20 23:07:49 -05:00
gboolean nm_agent_manager_all_agents_have_capability (NMAgentManager *manager,
settings: port NMAgentManager, etc, to use NMAuthSubject Rather than explicitly passing around a UID and a flag saying whether or not it's relevant. (This also fixes a bug where the wrong UID was being recorded in nm-settings-connection.c::auth_start(), which caused problems such as agent-owned secrets not getting saved because of a perceived UID mismatch.)
2013-11-05 14:36:38 -05:00
NMAuthSubject *subject,
vpn: handle interactive plugin secrets requests If all agents can handle VPN hints, then we'll try to use ConnectInteractive() to let the VPN plugin ask for secrets interactively via the SecretsRequired signal. These hints are then passed to agents during the connection process if the plugin needs more secrets or different secrets, and when the new secrets are returned, they are passed back to the VPN plugin. If at least one agent does not have the VPN hints capability, we can't use ConnectInteractive(), but fall back to the old Connect call, because that agent won't be able to send the hints to the VPN plugin's authentication dialog, and thus we won't get back the secrets the VPN plugin is looking for. So, for interactive secrets to work correctly, you need: 1) A VPN plugin updated for interactive secrets requests 2) NM updated for interactive secrets requests 3) all agents to set the VPN_HINTS capability when registering with NetworkManager and to pass hints along to the VPN authentication dialog 4) a VPN authentication dialog updated to look for hints and only return secrets corresponding to the hints requested by the plugin
2013-06-20 23:07:49 -05:00
NMSecretAgentCapabilities capability);
all: fix up multiple-include-guard defines Previously, src/nm-ip4-config.h, libnm/nm-ip4-config.h, and libnm-glib/nm-ip4-config.h all used "NM_IP4_CONFIG_H" as an include guard, which meant that nm-test-utils.h could not tell which of them was being included (and so, eg, if you tried to include nm-ip4-config.h in a libnm test, it would fail to compile because nm-test-utils.h was referring to symbols in src/nm-ip4-config.h). Fix this by changing the include guards in the non-API-stable parts of the tree: - libnm-glib/nm-ip4-config.h remains NM_IP4_CONFIG_H - libnm/nm-ip4-config.h now uses __NM_IP4_CONFIG_H__ - src/nm-ip4-config.h now uses __NETWORKMANAGER_IP4_CONFIG_H__ And likewise for all other headers. The two non-"nm"-prefixed headers, libnm/NetworkManager.h and src/NetworkManagerUtils.h are now __NETWORKMANAGER_H__ and __NETWORKMANAGER_UTILS_H__ respectively, which, while not entirely consistent with the general scheme, do still mostly make sense in isolation.
2014-08-13 14:10:11 -04:00
#endif /* __NETWORKMANAGER_AGENT_MANAGER_H__ */
Reference in a new issue Copy permalink