NMDBusObject already gets this right, by calling nm_dbus_utils_get_property(),
which calls g_dbus_gvalue_to_gvariant(), which correctly converts NULL
object paths to "/".
We already rely on that elsewhere. No need for this workaround.
In the loop, we invoke callbacks. What the callbacks do, is out of control
of NMAuthManager. For example, they could cancel or schedule new
requests. Especially, cancelling invalidate the stored @safe pointer.
Fix that, by always iterate from the start of the list.
Fixes: d0563f0733
In the first loop, the element is removed only when the callback is
executed. The second loop never removes the current element. Use the
for_each macro for both.
Fixes: d0563f0733
Requesting broadcast replies from the DHCP server can be problematic in
filtered environments like some wireless networks. Don't override the
default of using unicast. This matches the behaviour of the external DHCP
clients.
https://github.com/NetworkManager/NetworkManager/pull/93
The list of calls contains two kinds of elements: (1) calls that don't
need a D-Bus request and are only waiting for the asynchronous
invocation of the callback in an idle function; (2) calls that need a
D-Bus request and are waiting for the D-Bus proxy.
When the proxy creation finishes, only (2) calls must be canceled (if
the creation failed) or started (if the proxy was created).
Fixes: 798b2a7527https://bugzilla.redhat.com/show_bug.cgi?id=1567807
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.
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".
Up to now, it was not visible on D-Bus whether a connection
was generated by NetworkManager and/or volatile.
That is for example interesting for firewalld, which aims
to store persistant configuration in NetworkManager's profile.
However, that doesn't make sense for external connections
(which are nm-generated & volatile). In fact, it probably
makes no sense for volatile connections in general, because
modifying them, likely makes them non-volatile (depending on
how the profile is modified).
Also, the Update2() D-Bus operation allows to carefully
make connections volatile and unsaved. As we have public
API to set these flags, we should also expose them on D-Bus.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1460295
The D-Bus interface already has a boolean property "Unsaved".
While that is nicer too look at (in the API), adding a new flag
is very cumbersome, and also has more overhead. For example,
it requires extending the D-Bus API, all the way down to libnm.
Add a flags argument, that will allow to add future boolean
flags easier.
For one, these flags are "internal" flags. Soon, we will gain
a new NMSettingsConnectionFlags type that is exported on D-Bus
and partly overlaps with these internal flags. However, then we
will need the "flags" properties to expose the public bits.
This property only exists because other parts are interested in
notification signals. Note that we encourage NMDbusObject types
to freeze/thaw property-changed notifications. As freezing the
notifications also delays the signals, this is not desired for
the purpose where internal users subscribe to the signal.
"NMSettingsConnectionFlags" was an internal enum. Soon, we will add such
a type in libnm. Avoid the naming conflict by renaming. The "Int" stands
for "internal".
Add a new 'overview' command line option to make the output more
compact and display only properties that have non-default
values. Currently the option has only effect for the "connection show
$CON" sub-command.
$ nmcli -o connection show wifi-home
connection.id: wifi-home
connection.uuid: 8308c425-f2a7-4021-9afc-37bde7253c6d
connection.type: 802-11-wireless
connection.timestamp: 1519264421
connection.permissions: user:me
802-11-wireless.ssid: home
802-11-wireless.mode: infrastructure
802-11-wireless-security.key-mgmt: wpa-psk
802-11-wireless-security.auth-alg: open
ipv4.method: auto
ipv6.method: auto
https://bugzilla.redhat.com/show_bug.cgi?id=1434527
Add a new a new field to enum type descriptors that specify a list of
nicks valid only for getter functions. It is useful when the get
function must return a string different from the enum nick and that
string can't be used to set a value.
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: eabe7d856c
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.
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
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.
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.
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().
