| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
`nmcli con show`
|
|
|
|
|
|
|
| |
This will be necessary to sort a list of text that contains text to
replace. The use case is to get all UUIDs from the server, but some
of these UUIDs are dynamic. So, in order to have a fixed sort order,
we need to handle sorting the list, based on the replacement.
|
|
|
|
| |
Will be used to get all connection from the test stub server.
|
|
|
|
|
|
|
| |
We want to issue a nmcli command with the connection's UUID in the command
line. As the command line is stored to disk and compared, we cannot use UUIDs
that are randomly generated. Instead, we need to support replacing the text
in the command line.
|
|
|
|
|
|
|
| |
TestNmcli
It had no bad effect, but the cmd was a tuple with one string, and not
a string.
|
| |
|
|
|
|
|
|
| |
The variable name should say what it is, not what it is used for.
E.g. we would use the very same replacements for stderr. Rename
so that it can (by its name) used for different purposes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
g_atomic_pointer_compare_and_exchange()
../clients/cloud-setup/nmcs-provider-ec2.c:51:8: error: incompatible pointer types passing 'typeof ((((void *)0))) *' (aka 'void **') to parameter of type 'const char **' [-Werror,-Wincompatible-pointer-types]
if (!g_atomic_pointer_compare_and_exchange (&base_cached, NULL, base))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/glib-2.0/glib/gatomic.h:192:44: note: expanded from macro 'g_atomic_pointer_compare_and_exchange'
__atomic_compare_exchange_n ((atomic), &gapcae_oldval, (newval), FALSE, __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST) ? TRUE : FALSE; \
^~~~~~~~~~~~~~
and
../clients/cloud-setup/nmcs-provider-ec2.c:51:8: error: passing 'const char *' to parameter of type 'void *' discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers]
if (!g_atomic_pointer_compare_and_exchange ((void **) &base_cached, NULL, base))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/glib-2.0/glib/gatomic.h:222:55: note: expanded from macro 'g_atomic_pointer_compare_and_exchange'
__sync_bool_compare_and_swap ((atomic), (oldval), (newval)) ? TRUE : FALSE; \
^~~~~~~~
|
|
|
|
|
|
|
|
|
|
| |
Otherwise sendfile() fails with EINVAL when the file offset
is greater than zero (pos + size > max), always on the second
iteration.
Fixes: 0c6cd07ec81d ('nm-manager: remove lease file if copying dhclient lease fails')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/359
|
|
|
|
|
|
|
|
| |
If a device is being autoactivated and requires a parent that is
blocked due to user request, the autoactivation attempt should fail
because NM shouldn't overrule the user decision.
https://bugzilla.redhat.com/show_bug.cgi?id=1765566
|
|\
| |
| |
| |
| | |
https://bugzilla.redhat.com/show_bug.cgi?id=1779162
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/356
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Many device types take the MTU value from the wired setting; usually
they don't implement the can_reapply_change() method and so the MTU
can't be changed with the Reapply() API.
Instead of implementing the method for all such devices to support the
same property (adding a lot of duplicated code), add a check in
NMDevice to allow the reapply of MTU when we recognize that the device
uses the MTU from the wired setting.
Device types can still decide to implement can_reapply_change() and
support whatever properties they want, even from the wired setting.
|
|/ |
|
|\
| |
| |
| |
| |
| | |
https://bugzilla.redhat.com/show_bug.cgi?id=1762011
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/357
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
wrong configuration
No additional warnings are implemented yet.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
function
The underlying GPtrArray that we use to construct the list of warnings
is more useful than the strv array. For the internal function, don't
let it return the strv array but instead take (and fill) the warnings
as GPtrArray. There is no difference in practice, because also
previously we would always create an empty GPtrArray.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We always build with PolicyKit support enabled, because it has no
additional dependencies, beside some D-Bus calls.
However, in NetworkManager.conf the user could configure
"main.auth-polkit" to disable PolicyKit. However, previously it would
only allow to disable PolicyKit while granting access to all users.
I think it's useful to have an option that disables PolicyKit and grants
access only to root. I think we should not go too far in implementing
our own authorization mechanisms beside PolicyKit (e.g. you cannot
disable PolicyKit and grant access based on group membership of the
user). However, disabling PolicyKit can be useful sometimes, and it's
simple to implement a "root-only" setup.
Note one change is that when NetworkManager now runs without a D-Bus
connection (in initrd), it would deny all non-root requests. Previously
it would grant access. I think there should be little difference in
practice, because if we have no D-Bus we also don't have any requests to
authenticate.
|
|/
|
|
|
|
|
|
|
|
|
|
|
| |
We always build PolicyKit support, because it merely depends on some
D-Bus calls. However, there are two things to configure:
- the default value for main.auth-polkit in NetworkManager.conf. This
is now called "-Dconfig_auth_polkit_default=$VAL".
- whether to install the policy file. This is called "-Dpolkit=$VAL".
These settings are mostly independent, so add "config_auth_polkit_default" to
make the default explicitly configurable.
|
|
|
|
| |
- also use nm_auto_close and nm_close().
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When moving a lease file from initramfs directory to NetworkManager
run directory, SELinux label for that file retains tmpfs_t type.
Fix it by using sendfile() instead of rename(). That way, the
lease file will have the default type: NetworkManager_var_run_t.
Since we take ownership of the lease file, also drop it from the
old location.
* Before the patch:
ls -Z /var/run/NetworkManager/dhclient-*.lease
system_u:object_r:tmpfs_t:s0 dhclient-13162c00-abfb-4e28-bbfb-170187ddd044-ens3.lease
* After:
ls -Z /var/run/NetworkManager/dhclient-*.lease
system_u:object_r:NetworkManager_var_run_t:s0 dhclient-f47d1908-67ae-49c6-bd5e-19a690d85526-ens3.lease
Fixes: f2fe6c03ee3f ('manager: don't treat the initramfs-configured DHCP connections as generated')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/353
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Otherwise, other applications cannot bind to port 0.0.0.0:68 at the same time.
This is for example what dhclient wants to do. So even when running
dhclient on another, unrelated interface, it would fail to bind the UDP
socket and quit.
Note that also systemd-networkd's DHCPv4 client sets this socket option.
Presumably for the same reasons.
Signed-off-by: Thomas Haller <thaller@redhat.com>
https://github.com/nettools/n-dhcp4/pull/12
|
|
|
|
| |
https://bugzilla.redhat.com/show_bug.cgi?id=1745574
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLMNR and mDNS settings can have their global default value configured
in "NetworkManager.conf".
Global default values should work the way that all regular values of the property
can be configured explicitly in the connection profile. The special "default" value
only indicates to allow lookup of the global default, but it should not have a
meaning of its own.
Note that if mDNS/LLMNR settings are left unspecified, we will set the
argument to SetLinkMulticastDNS() and SetLinkLLMNR() functions to "",
which means that systemd-resolved decides on a default. Also, depending
on the DNS plugin, the default value differs. This is all fine however.
In this case, the ultimate default value depends on other things (like
the DNS plugin), but each possible value is in fact explicitly
configurable. We also do that for "ipv6.ip6-privacy".
Anyway, cleanup the documentation a bit and try to better explain what
the default is.
|
|\
| |
| |
| | |
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/355
|
| |
| |
| |
| | |
This affects nmtui and nm-cloud-setup, which use nmc_client_new_waitsync().
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This avoids unnecessarily fetching permissions, which are not needed
most of the time.
During `nmcli general permissions` we require to fetch the permissions. This is
now solved better, because previously the code waited for any permissions to be
not UNKNOWN. That was a hack, because there are cases where all permissions would
be UNKNOWN (hidepid mount option) and nmcli would hang.
There is a downside too: for `nmcli general permissions` we now first
need to wait for NMClient to initialize, before starting to fetch
permissions. Previously, we would call GetPermissions() in parallel
with initializing NMClient. It now takes longer.
That should be fixed be refactoring the code in nmcli to not wait for
NMClient to be fully initialized, before requesting the permissions.
|
| |
| |
| |
| |
| | |
This will allow us to set construct parameters to the instance, like
NM_CLIENT_INSTANCE_FLAGS.
|
| |
| |
| |
| | |
nm-online doesn't care about the permissions. Don't fetch them.
|
| |
| |
| |
| |
| | |
This will allow us to set construct parameters to the instance, like
NM_CLIENT_INSTANCE_FLAGS.
|
| |
| |
| |
| | |
nm-cloud-setup doesn't care about the permissions. Don't fetch them.
|
| | |
|
| |
| |
| |
| | |
nmtui doesn't care about the permissions. Don't fetch them.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Using sync init (nm_client_new()) has an overhead as it requires an internal
GMainContext to ensure preserving the order of D-Bus messages. Let's avoid
that by using the async init. Note that the difference here is that we will
iterate the caller's GMainContext while creating the instance. But that
is no problem for nmtui at that point.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Benefits:
- nmc_client_new_async*() allows to set properties on the NMClient
instance before calling g_async_initable_init_async().
It also allows to subscribe to any signals (like NM_CLIENT_DEVICE_ADDED)
before actually iterating the GMainContext. This is a sensible and
supported thing to do!
- nmc_client_new_waitsync() iterates the GMainContext until the (async)
initialization is complete. That is different from synchronous nm_client_new(),
which does not iterate the caller's GMainContext, and hence needs an
internal context to ensure the order of events is honored.
- nmc_client_new_waitsync() always returns the NMClient instance, even
if initialization fails.
That is useful if you need the nm_client_get_context_busy_watcher() instance
to ensure all pending messages are completed.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We have "shared/nm-libnm-core-aux", which is shared code that can be used
by anybody (including libnm-core, src, libnm and clients).
We have "clients/common", which are helper function for clients. But
that implies that the code is inside "clients". I think it would be
useful to have auxiliary code that extends libnm, but is not only
usable by code in "clients". In other words, "shared/nm-libnm-aux"
is a better place than "clients/common", and I think most of the
functionality form "clients/common" should move there.
|
| |
| |
| |
| |
| |
| |
| |
| | |
"shared/nm-glib-aux/tests"
"shared/nm-utils" got long renamed and split into separate parts. The remaining
tests are really to test nm-std-aux and nm-glib-aux (no libnm dependencies). Move
the tests to the appropriate place.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Currently, NMClient by default always fetches the permissions
("GetPermissions()") and refreshes them on "CheckPermissions" signal.
Fetching permissions is relatively expensive, while they are not used
most of the time. Allow the user to opt out of this.
For that, have a NMClientInstanceFlags to enable/disable automatic
fetching. Also add a "permissions-state" property that allows the user
to understand whether the cached permissions are up to date or not.
This is a bit an awkward API for handling this. E.g. you cannot
explicitly request permissions, you can just enable/disable fetching
permissions. And then you can watch the permission-state to know whether
you are ready. It's done this way because it fits the previous model
and extends the API with a (relative) small amount of new functions and
properties.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add a flags property to control behavior of NMClient.
Possible future use cases:
- currently it would always automatically fetch permissions. Often that
is not used and the user could opt out of it.
- currently, using sync init creates an internal GMainContext. This
has an overhead and may be undesirable. We could implement another
"sync" initialization that would merely iterate the callers mainloop
until the initialization completes. A flag would allow to opt in.
- currently, NMClient always fetches all connection settings
automatically. Via a flag the user could opt out of that.
Instead NMClient could provide an API so the user can request
settings as they are needed.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
On D-Bus, the permission names are just the PolicyKit action names, like
"org.freedesktop.NetworkManager.wifi.scan". But NMClient already
ignores all strings that it doesn't know at compile time and only
keeps track of well known permission.
And neither does the API nm_client_get_permissions_result() allow to
expose permissions unknown to libnm.
Maybe the API of NMClient should be more generic and allow exposing
any permissions announced by NetworkManager. As it is however, it's
not necessary to track the permissions in a hash table. An array with
fixed indices is sufficient.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In NetworkManager we have NMAuthCallResult, which is really a duplicate
of NMClientPermissionResult.
Maybe NMAuthCallResult should be entirely replaced by NMClientPermissionResult.
But the name NMClientPermissionResult is a bit awkward. But then the
duplication is even more awkward... fixing this is left for another day.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
impl_manager_get_permissions()
Reuse the list of all permissions and don't duplicate it.
Also, now the result of GetPermissions() on D-Bus contains the
permissions sorted by name. We get it almost for free, and it's
a nice property.
|
| | |
|
| |
| |
| |
| | |
nm_client_permission_result_from_string()
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
libnm-core
We will also use the enum from core.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
For example with
mount -o remount,rw,hidepid=1 /proc/
all permission checks will fail with an error. Internally, we map the
failure to NM_AUTH_CALL_RESULT_UNKNOWN.
<trace> [1575645672.5958] auth: call[1069]: CheckAuthorization(org.freedesktop.NetworkManager.enable-disable-connectivity-check), subject=unix-process[pid=468316, uid=1000, start=1912881]
<trace> [1575645672.6295] auth: call[1069]: completed: failed: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dfile_2derror_2dquark.Code4: Failed to open file “/proc/468316/status”: No such file or directory
<debug> [1575645672.6296] manager: unknown auth chain result 0
First of all, we should not log a debug message about that (we already log the
result of permission checks separately).
Also, we should include the unknown result in the response. The permission was
checked, and omitting it from GetPermissions() result seems wrong (even if we
failed to get the result).
Note that "unknown" is now a new possible return value on D-Bus. But
see how nm_permission_result_to_client() would map such a value to
"unknown" as well. So, it's probably a fine extension of the D-Bus API.
Note that NMClient API is currently quite limited. The user won't know
whether permissions were received (and if they were received, they
could not distinguish between UNKNOWN and absent). Hence, returning
all permissions as unknown (or not at all) causes `nmcli general permissions`
to hang. The solution here is to improve NMClient API to allow the user
to know when the permissions are received. But this patch doesn't
fix the hanging of nmcli nor the limitation of NMClient's API.
|