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

95 lines
4.4 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
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
#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: fill in nm-types.h, clean out other headers Clean up some of the cross-includes between headers (which made it so that, eg, if you included NetworkManagerUtils.h in a test program, you would need to build the test with -I$(top_srcdir)/src/platform, and if you included nm-device.h you'd need $(POLKIT_CFLAGS)) by moving all GObject struct definitions for src/ and src/settings/ into nm-types.h (which already existed to solve the NMDevice/NMActRequest circular references). Update various .c files to explicitly include the headers they used to get implicitly, and remove some now-unnecessary -I options from Makefiles.
2014-07-17 17:06:44 -04:00
struct _NMAgentManager {
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
NMExportedObject parent;
core: fill in nm-types.h, clean out other headers Clean up some of the cross-includes between headers (which made it so that, eg, if you included NetworkManagerUtils.h in a test program, you would need to build the test with -I$(top_srcdir)/src/platform, and if you included nm-device.h you'd need $(POLKIT_CFLAGS)) by moving all GObject struct definitions for src/ and src/settings/ into nm-types.h (which already existed to solve the NMDevice/NMActRequest circular references). Update various .c files to explicitly include the headers they used to get implicitly, and remove some now-unnecessary -I options from Makefiles.
2014-07-17 17:06:44 -04:00
};
agent: add agent manager and minimal agent class
2010-12-10 12:38:19 -06:00
typedef struct {
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
NMExportedObjectClass parent;
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
/* Signals */
void (*agent_registered) (NMAgentManager *agent_mgr, NMSecretAgent *agent);
agent: add agent manager and minimal agent class
2010-12-10 12:38:19 -06:00
} NMAgentManagerClass;
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
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,
guint32 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,
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
GHashTable *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,
gpointer user_data,
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
gpointer other_data2,
gpointer other_data3);
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
guint32 nm_agent_manager_get_secrets (NMAgentManager *manager,
NMConnection *connection,
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,
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
GHashTable *existing_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
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,
agents: change secrets request hints back to char ** Previously I didn't think they'd be used for anything other than connection secrets which only have one hint, but in the future we'll want to pass more information.
2013-06-19 17:51:09 -05:00
const char **hints,
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
NMAgentSecretsResultFunc callback,
gpointer callback_data,
gpointer other_data2,
gpointer other_data3);
void nm_agent_manager_cancel_secrets (NMAgentManager *manager,
guint32 request_id);
agent: add agent manager and minimal agent class
2010-12-10 12:38:19 -06:00
settings: implement saving secrets to agents on Update()
2011-01-31 23:10:33 -06:00
guint32 nm_agent_manager_save_secrets (NMAgentManager *manager,
NMConnection *connection,
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);
settings: implement saving secrets to agents on Update()
2011-01-31 23:10:33 -06:00
settings: implement deleting secrets from agents when connection is deleted
2011-01-31 23:33:46 -06:00
guint32 nm_agent_manager_delete_secrets (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
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