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

106 lines
4.9 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
*/
#ifndef NM_AGENT_MANAGER_H
#define NM_AGENT_MANAGER_H
#include <glib.h>
#include <glib-object.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
#include <nm-connection.h>
core: add nm-secrets-flags.h for secret agent flags typedef Make it clearer what's going on instead of using flags here and there and numbers elsewhere.
2011-03-29 22:53:22 -05:00
#include "nm-settings-flags.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))
Use glib-mkenums to generate enum types Rather than generating enum classes by hand (and complaining in each file that "this should really be standard"), use glib-mkenums. Unfortunately, we need a very new version of glib-mkenums in order to deal with NM's naming conventions and to fix a few other bugs, so just import that into the source tree temporarily. Also, to simplify the use of glib-mkenums, import Makefile.glib from https://bugzilla.gnome.org/654395. To avoid having to run glib-mkenums for every subdirectory of src/, add a new "generated" directory, and put the generated enums files there. Finally, use Makefile.glib for marshallers too, and generate separate ones for libnm-glib and NetworkManager.
2012-02-08 12:56:52 -05:00
typedef enum {
Fix names of error enum values When NM was registering all of its enum types by hand, it was using NamesLikeThis rather than the default names-like-this for the "nick" values. When we switched to using glib-mkenums, this resulted in dbus-glib using different strings for the D-Bus error names, causing compatibility problems. Fix this by using glib-mkenums annotations to manually fix all the enum values back to what they were before. (This can't be done in a more automated way, because the old names aren't 100% consistent. Eg, "UNKNOWN" frequently becomes "UnknownError" rather than just "Unknown".)
2012-03-09 09:39:58 -05:00
NM_AGENT_MANAGER_ERROR_SENDER_UNKNOWN = 0, /*< nick=SenderUnknown >*/
NM_AGENT_MANAGER_ERROR_PERMISSION_DENIED, /*< nick=PermissionDenied >*/
NM_AGENT_MANAGER_ERROR_SESSION_NOT_FOUND, /*< nick=SessionNotFound >*/
NM_AGENT_MANAGER_ERROR_INVALID_IDENTIFIER, /*< nick=InvalidIdentifier >*/
NM_AGENT_MANAGER_ERROR_NOT_REGISTERED, /*< nick=NotRegistered >*/
NM_AGENT_MANAGER_ERROR_INTERNAL_ERROR, /*< nick=InternalError >*/
NM_AGENT_MANAGER_ERROR_NO_SECRETS /*< nick=NoSecrets >*/
Use glib-mkenums to generate enum types Rather than generating enum classes by hand (and complaining in each file that "this should really be standard"), use glib-mkenums. Unfortunately, we need a very new version of glib-mkenums in order to deal with NM's naming conventions and to fix a few other bugs, so just import that into the source tree temporarily. Also, to simplify the use of glib-mkenums, import Makefile.glib from https://bugzilla.gnome.org/654395. To avoid having to run glib-mkenums for every subdirectory of src/, add a new "generated" directory, and put the generated enums files there. Finally, use Makefile.glib for marshallers too, and generate separate ones for libnm-glib and NetworkManager.
2012-02-08 12:56:52 -05:00
} NMAgentManagerError;
agent: add agent manager and minimal agent class
2010-12-10 12:38:19 -06:00
typedef struct {
GObject parent;
} NMAgentManager;
typedef struct {
GObjectClass 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,
core: add nm-secrets-flags.h for secret agent flags typedef Make it clearer what's going on instead of using flags here and there and numbers elsewhere.
2011-03-29 22:53:22 -05:00
NMSettingsGetSecretsFlags 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,
core: add nm-secrets-flags.h for secret agent flags typedef Make it clearer what's going on instead of using flags here and there and numbers elsewhere.
2011-03-29 22:53:22 -05:00
NMSettingsGetSecretsFlags 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);
agent: add agent manager and minimal agent class
2010-12-10 12:38:19 -06:00
#endif /* NM_AGENT_MANAGER_H */
Reference in a new issue Copy permalink