| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of setting multiple callbacks, just let the user set one
vtable with callbacks. Usually, GObject would implement this via
signals. While that makes sense for public objects, for example to
work better with GIR and allow intercepting the signal, this is
overkill for our internal type. And NMPolkitListener already did
not make use of signals, for good reason.
Instead of passing multiple callbacks, must pass one structure with
callback pointers.
Also, extend the signature of the callbacks to always contain a
@self argument and a @user_data.
|
|
|
|
| |
Follow a standard order for the code.
|
|
|
|
|
|
|
|
| |
Some cleanup of the includes. For example, immediately after
"nm-default.h" include the header file for the current source.
Also, move the use of the "#if WITH_POLKIT_AGENT" conditionals
closer together. E.g. don't use the #if in "nmcli.h".
|
|
|
|
|
| |
Drop the g_assert(), which is always compiled in, but obviously
can never fail.
|
|
|
|
|
| |
We will also use it in nmcli later. It will be needed when we replace
polkit_unix_process_new_for_owner(). Which is still far down the road.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We don't want to apped the value to @buf, we want to set it.
Also, if @buf happens to be uninitialized, g_strlcat() might
determine there is nothing to append and return the buffer unmodified.
Then, the (non NULL terminated) buffer might be printed.
Note that before recent refactoring, we effectively would only call
nm_auth_subject_to_string() on auth-subjects that were of type
UNIX-PROCESS. Hence, this bug came only to light very recently,
although it was present for a long time.
Fixes: eabe7d856c243673bbaba3295ce74d72e188596d
|
| |
|
|
|
|
|
|
|
| |
We also don't emit the PropertiesChanged signal while connections are
not loaded. Maybe that is wrong, in any case, the property should agree
with the way how we emit notifications. So, for now, make the property
agree with not notifying about connections during startup.
|
|
|
|
|
| |
dispose() should be re-entrant. When releasing a resource, it must not
leave a dangling pointer. While at it, just move it to finalize() instead.
|
| |
|
|
|
|
|
|
|
| |
Also, take a reference of the NMSettingsConnection while
it is being tracked by NMSettings' list.
Fixes: 1f3b47deea84888813ed482f5b3e75292b0f2726
|
| |
|
|
|
|
|
|
|
|
|
| |
Use the same form everywhere: "TRANSLATORS" instead of "Translators".
The manual also seems to prefer the upper-case form [1].
$ sed 's/\<Translators\>: /TRANSLATORS: /g' $(git grep -l Translators) -i
[1] https://www.gnu.org/software/gettext/manual/gettext.html
|
|\
| |
| |
| | |
https://github.com/NetworkManager/NetworkManager/pull/85
|
| |
| |
| |
| |
| |
| |
| |
| | |
It makes sense to use NMAuthChain also when not attaching any user-data to
the chain. The main reason would be, the ability to schedule multiple permission
checks in parallel, and wait for them to complete together.
Only allocate the hash-table, when we really need it.
|
| |
| |
| |
| |
| | |
We already use "data" for other places. Let's use unique names
that can be searched within one file.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
More of a proof of concept, how convenient (or not) it is to drop
NMAuthChain and use NMAuthManager's API directly. I think it's
reasonably nice.
As before, when asking for both general network-control permissions
and wifi-shared-permissions, we will not fail with
wifi-shared-permissions, as long as network-control check is still
pending. The effect is, that the error response preferably complains
about no permissions to network-control (in case both permissions
are missing).
One change in behavior is, if network-control authorization check
fails before wifi-shared-permissions, we declare the result and
cancel the pending wifi-shared-permissions. Previously, we would
have waited for both results. The change in behavior is not merely
that we declare the result earlier, but also that NMAuthManager will
actively send a "CancelCheckAuthorization" D-Bus call to cancel the
still pending wifi-shared-permissions check.
|
| |
| |
| |
| |
| |
| |
| | |
For one, we already do <trace> level logging inside NMAuthManager.
So, at trace level we have everything.
If a request fails, it's not up to NMAuthChain to log a warning.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Get rid of the NMAuthChain layer.
I think NMAuthChain only makes sense if we schedule multiple requests
together for the same topic. But NMSettingsConnection never does that:
each D-Bus request corresponds to only one polkit authorization request.
So, we can just call NMAuthManager directly.
|
| |
| |
| |
| |
| |
| |
| | |
Otherwise, the autorization request might succeed and we would
still do something with the connection that is already removed.
https://bugzilla.redhat.com/show_bug.cgi?id=1565030
|
| |
| |
| |
| |
| |
| |
| | |
This makes NMAuthCallResult not only usable from within a NMAuthChain.
It makes sense to just call nm-auth-manager directly, but then we need
a way to convert the more detailed result into an NMAuthCallResult
value.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
NMAuthChain's nm_auth_chain_add_call() used to add special handling for
the NMAuthSubject. This handling really belongs to NMAuthManager for two
reasons:
- NMAuthManager already goes through the effort of scheduling an idle
handler to handle the case where no GDBusProxy is present. It can
just as well handle the special cases where polkit-auth is disabled
or when we have internal requests.
- by NMAuthChain doing special handling, it makes it more complicated
to call nm_auth_manager_check_authorization() directly. Previously,
the NMAuthChain had additional logic, which means you either were
forced to create an NMAuthChain, or you had to reimplement special
handling like nm_auth_chain_add_call().
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Supporting PolicyKit required no additional library, just extra code
to handle the D-Bus calls. For that, there was a compile time option
to even stip out that code. Note, that you could (and still can)
configure the system not to use policy-kit. The point was to reduce
the binary size in case you don't need it.
Remove this. I guess, we we aim for such aggressive optimization of
the binary size, we should instead make all device types disablable
at configuration time. We don't do that either and other low hanging
fruits, because it's better to always enable features, unless they
require external dependencies.
Also, the next commit will make more use of NMAuthManager. So, having
it disabled at compile time, makes even less sense.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Don't use the GAsyncResult pattern for internal API of auth-manager. Instead,
use a simpler API that has a more strict API and simpler use.
- return a call-id handle when scheduling the authorization request.
The request is always scheduled asynchronsously and thus call-id
is never %NULL.
- the call-id can be used to cancel the request. It can be used exactly
once, and only before the callback is invoked.
- the async keeps the auth-manager alive. It needs to do so, because
when cancelling the request we might not yet be done: instead we
might still need to issue a CancelCheckAuthorization call (which
we need to handle as well).
- the callback is always invoked exactly once.
Currently NMAuthManager's API effectivly is only called by NMAuthChain.
The point of this is to make NMAuthManager's API more consumable, and
thus let users use it directly (instead of using the NMAuthChain layer).
As well known, we don't do a good job during shutdown of NetworkManager
to release all resources and cancel pending requests. This rework also
makes it possible to actually get this right. See the comment in
nm_auth_manager_force_shutdown(). But yes, it is still a bit complicated
to do a controlled shutdown, because we cannot just synchronously
complete. We need to issue CancelCheckAuthorization D-Bus calls, and
give these requests time to complete. The new API introduced by this patch
would make that easier.
|
| |
| |
| |
| |
| |
| | |
We need the setter, because we want that the property is set only
once during creation of the instance. Nobody cares about the GObject
property getter otherwise.
|
| |
| |
| |
| |
| |
| |
| | |
It's more efficient, as it saves a lookup by name. Also,
it's more idiomatic to do it this way. I didn't find where
the signal gets emitted at first, because usually we don't emit
by name.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
NMAuthChain schedules (possibly) multiple authentication requests.
When they all complete, it will once invoke the result-callback.
There is no need to schedule this result-callback on another idle-handler,
because nm_auth_manager_polkit_authority_check_authorization() should guarantee
to invoke the callback never-synchronously and on a clean call-stack (to avoid
problems with re-entrancy). At that point, NMAuthChain does not need to
delay this further.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
NMAuthChain is not really ref-counted. True, we have an internal ref-counter
to ensure that the instance stays alive while the callback is invoked. However,
the user cannot take additional references as there is no nm_auth_chain_ref().
When the user wants to get rid of the auth-chain, with the current API it
is important that the callback won't be called after that point. From the
name nm_auth_chain_unref(), it sounds like that there could be multiple references
to the auth-chain, and merely unreferencing the object might not guarantee that
the callback is canceled. However, that is luckily not the case, because
there is no real ref-counting involved here.
Just rename the destroy function to make this clearer.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When one D-Bus object exposes (the path of) another D-Bus object,
we want that the path property gets cleared before the other
object gets unexported(). That essentially requires to register
to the "exported-changed" signal.
Add a helper struct NMDBusTrackObjPath to help with this.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When a settings-connection gets deleted, we need to bring down the
NMActiveConnection that contains it. However, we shouldn't just unexport
the active connection from D-Bus. Instead, clear the settings path.
We need to drop the path, because the connection is going away. It's a
bit ugly, that an active-connection might reference no
settings-connection. However, this only happens during shut-down.
The alternative, would be to keep the settings-connection object
in a zombie state, exported on D-Bus. However, that seems even more
confusing to me.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The GObject property "path" exists for the sole reasons so that
other components can connect to the "notify::path" signal.
However, notifications are blocked by g_object_freeze_notify(),
and especially for NMDBusObject we want to make use of that to
combine multiple PropertiesChanged events into one.
This blocking of the signal is not desired for the case where
we wait for "notify::path". Convert that to a signal, which
will not be blocked.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
NMSettings already references NMSettingsConnection. Hence, it should not
at the same time reference itself. Arguably, during shutdown we do not properly
release all NMSettingsConnection. For example, there is no nm_settings_stop().
But that is a bug that needs fixing.
No need to keep the NMSettings instance alive here. If this is really
necessary, it needs fixing somewhere else. Besides, we know that we leak
a lot during shutdown, so this needs more work to do a clean shutdown.
|
| |
| |
| |
| | |
It makes more sense to me this way.
|
| |
| |
| |
| |
| |
| | |
We only need @state, after we verified that the active connection
references the right settings connection. Most of the time, that
is not the case.
|
| |
| |
| |
| |
| |
| | |
We dopped NMConnectionProvider a while ago. Forgot something.
Fixes: 5337003c4cd946860c6bea98164874f8c4aed5e7
|
| |
| |
| |
| |
| | |
Add some assertion, use an unsigned loop variable (that matches
GPtrArray.len type), and add a comment.
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Server never sets the path, so this is entirely unused server-side.
Also NMConnection is a glib interface and stores it's private date
in the GObject's data. It's less efficient to look it up. Just
avoid it.
|
| |
| |
| |
| | |
It's unused.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
No longer rely on nm_connection_get_path() being meaningful in server.
It also was wrong. During update, nm_settings_connection_update()
would call
nm_utils_log_connection_diff (replace_connection, NM_CONNECTION (self), ...
where replace_connection has no path set, and nothing was logged.
Fix it, by explicitly passing the D-Bus path. Also, because
nm-core-utils.c should be independent of nm-dbus-object.h.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Essentially, nm_connection_get_path() mirros nm_dbus_object_get_path().
However, when cloning a simple-connection, the path also gets cloned.
I think this field doesn't belong to NMConnection in the first place,
because NMConnection is not a D-Bus object. NMSettingsConnection (in
core) and NMRemoteConnection (in libnm) is.
Don't use the misleading alias, but use nm_dbus_object_get_path()
directly.
|
| |
| |
| |
| |
| |
| | |
GPtrArrray
Fixes: c050fb7cd2160f0b74ba8a0760e717e3fe329066
|
| |
| |
| |
| | |
At that point, the path becomes meaningless. Clear it.
|
| | |
|
| |
| |
| |
| | |
connection_removed()
|
| |
| |
| |
| |
| |
| | |
This wasn't a problem, because load_plugins() can only fails
if the settings plugins fail to load, which can only happen
if you have a broken installation.
|