2019-09-10 11:19:01 +02:00
|
|
|
// SPDX-License-Identifier: GPL-2.0+
|
2019-09-25 13:13:40 +02:00
|
|
|
/*
|
2019-10-01 09:20:35 +02:00
|
|
|
* Copyright (C) 2005 - 2012 Red Hat, Inc.
|
2005-05-03 Dan Williams <dcbw@redhat.com>
* Kill dhcpcd. We now use "dhcdbd", a dbus daemon that controls dhclient.
This means that NetworkManager shouldn't have DHCP issues anymore. It also
means you need dhcdbd, which you can get here (get the latest one):
http://people.redhat.com/jvdias/dhcdbd/
Technically NetworkManager can use any DHCP daemon that uses the same DBUS
interface as dhcdbd.
* Rewrite device activation to facilitate the new DHCP infrastructure and
future improvements. Its now "activation request" based, ie there is a single
activation request composed of the device, access point, and other info which
follows the entire activation process. There are 5 stages of the activation
process which correspond to:
1) Device preparation
2) Device configuration (bring it up, set ESSID/Key/etc)
3) IP Config Start (fire off DHCP if we're using it)
4) IP Config Get (grab config from DHCP or static config files)
5) IP Config Commit (set device's IP address, DNS, etc)
Note that there is no longer a "scanning" step, since the access point must
be known _before_ activation starts. If the access point drops out or does
not exist for some reason, the entire activation process fails and must be
restarted for a different access point or device.
Patch from Bill Moss:
* gnome/applet/applet.c
- Fix type of vpn_failure dialog -> vpn_banner dialog
git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@597 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-05-03 20:41:36 +00:00
|
|
|
*/
|
|
|
|
|
|
2016-09-28 19:37:10 +02:00
|
|
|
#ifndef __NM_ACT_REQUEST_H__
|
|
|
|
|
#define __NM_ACT_REQUEST_H__
|
2005-05-03 Dan Williams <dcbw@redhat.com>
* Kill dhcpcd. We now use "dhcdbd", a dbus daemon that controls dhclient.
This means that NetworkManager shouldn't have DHCP issues anymore. It also
means you need dhcdbd, which you can get here (get the latest one):
http://people.redhat.com/jvdias/dhcdbd/
Technically NetworkManager can use any DHCP daemon that uses the same DBUS
interface as dhcdbd.
* Rewrite device activation to facilitate the new DHCP infrastructure and
future improvements. Its now "activation request" based, ie there is a single
activation request composed of the device, access point, and other info which
follows the entire activation process. There are 5 stages of the activation
process which correspond to:
1) Device preparation
2) Device configuration (bring it up, set ESSID/Key/etc)
3) IP Config Start (fire off DHCP if we're using it)
4) IP Config Get (grab config from DHCP or static config files)
5) IP Config Commit (set device's IP address, DNS, etc)
Note that there is no longer a "scanning" step, since the access point must
be known _before_ activation starts. If the access point drops out or does
not exist for some reason, the entire activation process fails and must be
restarted for a different access point or device.
Patch from Bill Moss:
* gnome/applet/applet.c
- Fix type of vpn_failure dialog -> vpn_banner dialog
git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@597 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-05-03 20:41:36 +00:00
|
|
|
|
2007-05-07 15:17:45 +00:00
|
|
|
#include "nm-connection.h"
|
2008-03-26 13:43:01 +00:00
|
|
|
#include "nm-active-connection.h"
|
2005-05-03 Dan Williams <dcbw@redhat.com>
* Kill dhcpcd. We now use "dhcdbd", a dbus daemon that controls dhclient.
This means that NetworkManager shouldn't have DHCP issues anymore. It also
means you need dhcdbd, which you can get here (get the latest one):
http://people.redhat.com/jvdias/dhcdbd/
Technically NetworkManager can use any DHCP daemon that uses the same DBUS
interface as dhcdbd.
* Rewrite device activation to facilitate the new DHCP infrastructure and
future improvements. Its now "activation request" based, ie there is a single
activation request composed of the device, access point, and other info which
follows the entire activation process. There are 5 stages of the activation
process which correspond to:
1) Device preparation
2) Device configuration (bring it up, set ESSID/Key/etc)
3) IP Config Start (fire off DHCP if we're using it)
4) IP Config Get (grab config from DHCP or static config files)
5) IP Config Commit (set device's IP address, DNS, etc)
Note that there is no longer a "scanning" step, since the access point must
be known _before_ activation starts. If the access point drops out or does
not exist for some reason, the entire activation process fails and must be
restarted for a different access point or device.
Patch from Bill Moss:
* gnome/applet/applet.c
- Fix type of vpn_failure dialog -> vpn_banner dialog
git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@597 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-05-03 20:41:36 +00:00
|
|
|
|
2007-06-11 13:36:34 +00:00
|
|
|
#define NM_TYPE_ACT_REQUEST (nm_act_request_get_type ())
|
|
|
|
|
#define NM_ACT_REQUEST(obj) (G_TYPE_CHECK_INSTANCE_CAST ((obj), NM_TYPE_ACT_REQUEST, NMActRequest))
|
|
|
|
|
#define NM_ACT_REQUEST_CLASS(klass) (G_TYPE_CHECK_CLASS_CAST ((klass), NM_TYPE_ACT_REQUEST, NMActRequestClass))
|
|
|
|
|
#define NM_IS_ACT_REQUEST(obj) (G_TYPE_CHECK_INSTANCE_TYPE ((obj), NM_TYPE_ACT_REQUEST))
|
2012-07-27 13:15:54 +02:00
|
|
|
#define NM_IS_ACT_REQUEST_CLASS(klass) (G_TYPE_CHECK_CLASS_TYPE ((klass), NM_TYPE_ACT_REQUEST))
|
2007-06-11 13:36:34 +00:00
|
|
|
#define NM_ACT_REQUEST_GET_CLASS(obj) (G_TYPE_INSTANCE_GET_CLASS ((obj), NM_TYPE_ACT_REQUEST, NMActRequestClass))
|
2005-05-03 Dan Williams <dcbw@redhat.com>
* Kill dhcpcd. We now use "dhcdbd", a dbus daemon that controls dhclient.
This means that NetworkManager shouldn't have DHCP issues anymore. It also
means you need dhcdbd, which you can get here (get the latest one):
http://people.redhat.com/jvdias/dhcdbd/
Technically NetworkManager can use any DHCP daemon that uses the same DBUS
interface as dhcdbd.
* Rewrite device activation to facilitate the new DHCP infrastructure and
future improvements. Its now "activation request" based, ie there is a single
activation request composed of the device, access point, and other info which
follows the entire activation process. There are 5 stages of the activation
process which correspond to:
1) Device preparation
2) Device configuration (bring it up, set ESSID/Key/etc)
3) IP Config Start (fire off DHCP if we're using it)
4) IP Config Get (grab config from DHCP or static config files)
5) IP Config Commit (set device's IP address, DNS, etc)
Note that there is no longer a "scanning" step, since the access point must
be known _before_ activation starts. If the access point drops out or does
not exist for some reason, the entire activation process fails and must be
restarted for a different access point or device.
Patch from Bill Moss:
* gnome/applet/applet.c
- Fix type of vpn_failure dialog -> vpn_banner dialog
git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@597 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-05-03 20:41:36 +00: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
|
|
|
struct _NMActRequestGetSecretsCallId;
|
2017-11-24 16:24:40 +01:00
|
|
|
typedef struct _NMActRequestGetSecretsCallId NMActRequestGetSecretsCallId;
|
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
|
|
|
|
2007-06-11 13:36:34 +00:00
|
|
|
GType nm_act_request_get_type (void);
|
2005-05-03 Dan Williams <dcbw@redhat.com>
* Kill dhcpcd. We now use "dhcdbd", a dbus daemon that controls dhclient.
This means that NetworkManager shouldn't have DHCP issues anymore. It also
means you need dhcdbd, which you can get here (get the latest one):
http://people.redhat.com/jvdias/dhcdbd/
Technically NetworkManager can use any DHCP daemon that uses the same DBUS
interface as dhcdbd.
* Rewrite device activation to facilitate the new DHCP infrastructure and
future improvements. Its now "activation request" based, ie there is a single
activation request composed of the device, access point, and other info which
follows the entire activation process. There are 5 stages of the activation
process which correspond to:
1) Device preparation
2) Device configuration (bring it up, set ESSID/Key/etc)
3) IP Config Start (fire off DHCP if we're using it)
4) IP Config Get (grab config from DHCP or static config files)
5) IP Config Commit (set device's IP address, DNS, etc)
Note that there is no longer a "scanning" step, since the access point must
be known _before_ activation starts. If the access point drops out or does
not exist for some reason, the entire activation process fails and must be
restarted for a different access point or device.
Patch from Bill Moss:
* gnome/applet/applet.c
- Fix type of vpn_failure dialog -> vpn_banner dialog
git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@597 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
2005-05-03 20:41:36 +00:00
|
|
|
|
2015-07-14 16:53:24 +02:00
|
|
|
NMActRequest *nm_act_request_new (NMSettingsConnection *settings_connection,
|
2016-09-07 17:47:26 +02:00
|
|
|
NMConnection *applied_connection,
|
2007-09-14 19:43:28 +00:00
|
|
|
const char *specific_object,
|
2013-07-29 13:11:47 -05:00
|
|
|
NMAuthSubject *subject,
|
2017-03-07 11:04:36 +01:00
|
|
|
NMActivationType activation_type,
|
2018-03-28 17:18:04 +02:00
|
|
|
NMActivationReason activation_reason,
|
core: improve and fix keeping connection active based on "connection.permissions"
By setting "connection.permissions", a profile is restricted to a
particular user.
That means for example, that another user cannot see, modify, delete,
activate or deactivate the profile. It also means, that the profile
will only autoconnect when the user is logged in (has a session).
Note that root is always able to activate the profile. Likewise, the
user is also allowed to manually activate the own profile, even if no
session currently exists (which can easily happen with `sudo`).
When the user logs out (the session goes away), we want do disconnect
the profile, however there are conflicting goals here:
1) if the profile was activate by root user, then logging out the user
should not disconnect the profile. The patch fixes that by not
binding the activation to the connection, if the activation is done
by the root user.
2) if the profile was activated by the owner when it had no session,
then it should stay alive until the user logs in (once) and logs
out again. This is already handled by the previous commit.
Yes, this point is odd. If you first do
$ sudo -u $OTHER_USER nmcli connection up $PROFILE
the profile activates despite not having a session. If you then
$ ssh guest@localhost nmcli device
you'll still see the profile active. However, the moment the SSH session
ends, a session closes and the profile disconnects. It's unclear, how to
solve that any better. I think, a user who cares about this, should not
activate the profile without having a session in the first place.
There are quite some special cases, in particular with internal
activations. In those cases we need to decide whether to bind the
activation to the profile's visibility.
Also, expose the "bind" setting in the D-Bus API. Note, that in the future
this flag may be modified via D-Bus API. Like we may also add related API
that allows to tweak the lifetime of the activation.
Also, I think we broke handling of connection visiblity with 37e8c53eeed
"core: Introduce helper class to track connection keep alive". This
should be fixed now too, with improved behavior.
Fixes: 37e8c53eeed579fe34a68819cd12f3295d581394
https://bugzilla.redhat.com/show_bug.cgi?id=1530977
2018-11-21 13:30:16 +01:00
|
|
|
NMActivationStateFlags initial_state_flags,
|
2013-07-29 16:26:09 -05:00
|
|
|
NMDevice *device);
|
2007-09-14 19:43:28 +00:00
|
|
|
|
2015-07-14 16:53:24 +02:00
|
|
|
NMSettingsConnection *nm_act_request_get_settings_connection (NMActRequest *req);
|
2007-06-11 13:36:34 +00:00
|
|
|
|
2015-07-14 16:53:24 +02:00
|
|
|
NMConnection *nm_act_request_get_applied_connection (NMActRequest *req);
|
2008-06-10 02:02:21 +00:00
|
|
|
|
2015-07-14 16:53:24 +02:00
|
|
|
gboolean nm_act_request_get_shared (NMActRequest *req);
|
2008-06-10 02:02:21 +00:00
|
|
|
|
2015-07-14 16:53:24 +02:00
|
|
|
void nm_act_request_set_shared (NMActRequest *req, gboolean shared);
|
|
|
|
|
|
|
|
|
|
void nm_act_request_add_share_rule (NMActRequest *req,
|
|
|
|
|
const char *table,
|
|
|
|
|
const char *rule);
|
2008-08-15 15:34:28 +00:00
|
|
|
|
2010-12-13 13:11:51 -06:00
|
|
|
/* Secrets handling */
|
|
|
|
|
|
|
|
|
|
typedef void (*NMActRequestSecretsFunc) (NMActRequest *req,
|
2017-11-24 16:24:40 +01:00
|
|
|
NMActRequestGetSecretsCallId *call_id,
|
2015-07-14 16:53:24 +02:00
|
|
|
NMSettingsConnection *connection,
|
2010-12-13 13:11:51 -06:00
|
|
|
GError *error,
|
|
|
|
|
gpointer user_data);
|
|
|
|
|
|
2017-11-24 16:24:40 +01:00
|
|
|
NMActRequestGetSecretsCallId *nm_act_request_get_secrets (NMActRequest *req,
|
|
|
|
|
gboolean take_ref,
|
|
|
|
|
const char *setting_name,
|
|
|
|
|
NMSecretAgentGetSecretsFlags flags,
|
2019-01-24 16:18:56 +01:00
|
|
|
const char *const*hints,
|
2017-11-24 16:24:40 +01:00
|
|
|
NMActRequestSecretsFunc callback,
|
|
|
|
|
gpointer callback_data);
|
2010-12-13 13:11:51 -06:00
|
|
|
|
2017-11-24 16:24:40 +01:00
|
|
|
void nm_act_request_cancel_secrets (NMActRequest *req, NMActRequestGetSecretsCallId *call_id);
|
2015-07-14 16:53:24 +02:00
|
|
|
void nm_act_request_clear_secrets (NMActRequest *self);
|
2009-06-11 00:39:12 -04:00
|
|
|
|
2016-09-28 19:37:10 +02:00
|
|
|
#endif /* __NM_ACT_REQUEST_H__ */
|
2009-06-11 00:39:12 -04:00
|
|
|
|
