nm_g_error_matches() can be inlined and first checks whether the error
argument is not NULL. At least from the keyfile accessor functions, use
this macro, as they are called many times.
Macros preferably behave function-like, for example in that they evaluate
arguments exactly ones. Sometimes, we want to evaluate arguments
lazily, like in NM_IN_SET() or nm_g_set_error_take_lazy(). But it
is almost always undesirable to evaluate an argument more than once.
Fix NM_STR_HAS_PREFIX() for that.
Also, rename the local variable to not use the name "_str",
which may be a common name that the caller would like to use.
GPtrArray does not support NULL terminating the pointer array. That
makes it cumbersome to use it for tracking a strv array. Add a few
helper functions nm_strvarray_*() that help using a GArray instead.
We had three callers of nm_keyfile_plugin_kf_get_integer_list(). Two
only wanted to read values in range of guint8. One, wanted to read
unsigned integers (for which nm_keyfile_plugin_kf_get_integer_list()
was not suitable).
Instead, implement a integer list reader ourself.
One change is that g_key_file_get_integer_list() would accept list elements
with a number followed by a white space and garbage ([1]). We don't do that,
so there is a change in behavior here. That seems preferable, we don't
want to accept garbage.
The error reason text from the reader now also changes, and obviously we
no longer fail for integer values larger than G_MAXINT.
[1] c9bf247eb9/glib/gkeyfile.c (L4445)
Keyfile handles GObject properties of type G_TYPE_ARRAY as a GArray
of unsigned ints. That is correct, because all our properties of this
GType happen to be of this kind.
However, then the function was using nm_keyfile_plugin_kf_set_integer_list(),
which only can handle signed integers. There was thus an assertion that all
integers were non-negative. Which, probably was also correct, because NMSettingDcb
would validate that all values of such kind are in fact positive. Anyway, that
is an unexpected limitation (if not a bug).
Fix that by handling the array as unsigned list of integers.
Also, since glib doesn't provide an API for storing lists of unsigend
integers, we have to implement our own. but that is no loss. We probably
do it better anyway.
Previously, we were preallocating a string buffer of fixed size. For guint8
we reserved 3 characters per number, which is sufficient. However, it is
not obviously sufficient. NMStrBuf would grow as needed.
Next, I will add nm_keyfile_plugin_kf_set_integer_list_uint(), where it
is more unclear how large the string can be at most. To avoid that question
from the start, it will use NMStrBuf. To keep the implementations similar,
use NMStrBuf also in this case.
Split the macros to define the setter and getter so that setters
and getters are defined by separate macros. This will be used
to define the boolean getter differently, but still using the
macro to define the setter.
Also, don't construct function names in the macro. Instead, pass
the full names as argument to the macro. This helps with the problem
where ctags/cscope is unable to locate the implementation of the
function. Since we define the function with macro, the tools still
don't recognize this as the location of the definition. But at least
when showing all occurrences of the name, it can be found.
Currently any error encountered in n_dhcp4_c_connection_dispatch_io()
causes a dispatch failure and interrupts the library state
machine. The recvmsg() on the socket can fail for different reasons;
one of these is for example that the UDP request previously sent got a
ICMP port-unreachable response. This can be reproduced in the
following way:
ip netns add ns1
ip link add veth0 type veth peer name veth1
ip link set veth1 netns ns1
ip link set veth0 up
cat > dhcpd.conf <<EOF
server-identifier 172.25.0.1;
max-lease-time 120;
default-lease-time 120;
subnet 172.25.0.0 netmask 255.255.255.0 {
range 172.25.0.100 172.25.0.200;
}
EOF
ip -n ns1 link set veth1 up
ip -n ns1 address add dev veth1 172.25.0.1/24
ip netns exec ns1 iptables -A INPUT -p udp --dport 67 -j REJECT
ip netns exec ns1 dhcpd -4 -cf dhcpd.conf -pf /tmp/dhcp-server.pid
If a client is started on veth0, it is able to obtain a lease despite
the firewall rule blocking DHCP, because dhcpd uses a packet
socket. Then it fails during the renewal because the recvmsg() fails:
dhcp4 (veth0): send REQUEST of 172.25.0.178 to 172.25.0.1
dhcp4 (veth0): error -111 dispatching events
dhcp4 (veth0): state changed bound -> fail
The client should consider such errors non fatal and keep running.
https://bugzilla.redhat.com/show_bug.cgi?id=1829178https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/486
In general, I like macros. But in this case it seems the make the code harder
to understand than it needs to be. There are repeated patterns in these declarations,
but I feel they are better recognizible by aligning the lines nicely.
When handling a GCancellable, you make decisions based on when the cancelled
property of a GCancellable changes. Correctly handling a cancellable becoming
uncancelled again is really complicated, nor is it clear what it even means:
should the flipping be treated as cancellation or not? Probably if the
cancelled property gets reset, you already start aborting and there is
no way back. So, you would want that a cancellation is always handled.
But it's hard to implement that correctly, and it's odd to claim
something was cancelled, if g_cancellable_is_cancelled() doesn't agree
(anymore).
Avoid such problems by preventing users to call g_cancellable_reset().
Conceptionally, the MUD URL really depends on the device, and not so
much the connection profile. That is, when you have a specific IoT
device, then this device probably should use the same MUD URL for all
profiles (at least by default).
We already have a mechanism for that: global connection defaults. Use
that. This allows a vendor drop pre-install a file
"/usr/lib/NetworkManager/conf.d/10-mud-url.conf" with
[connection-10-mud-url]
connection.mud-url=https://example.com
Note that we introduce the special "connection.mud-url" value "none", to
indicate not to use a MUD URL (but also not to consult the global connection
default).
Add nm_utils_invoke_on_timeout() beside nm_utils_invoke_on_idle().
They are fundamentally similar, except one schedules an idle handler
and the other a timeout.
Also, use the current g_main_context_get_thread_default() as context
instead of the singleton instance. That is a change in behavior, but
the only caller of nm_utils_invoke_on_idle() is the daemon, which
doesn't use different main contexts. Anyway, to avoid anybody being
tripped up by this also change the order of arguments. It anyway
seems nicer to first pass the cancellable, and the callback and user
data as last arguments. It's more in line with glib's asynchronous
methods.
Also, in the unlikely case that the cancellable is already cancelled
from the start, always schedule an idle action to complete fast.
Why "if (length > G_MAXUINT)"? This is never going to hit. Also,
we probably should actual missing keys handle differently from
empty lists. If @error is set, return without setting the property.
g_key_file_get_integer_list() can return %NULL without setting an error.
That is the case if the key is set to an empty value.
For X sake, this API. Read the documentation and figure out whether
the function can return %NULL without reporting an error.
Anyway, avoid the assertion failure.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/412
- in io_watch_have_data(), ensure that we handle incomplete lines
that don't yet have a newline by waiting for more data. That means,
if the current content of the in_buffer does not have a newline, we
wait longer.
- in io_watch_have_data(), implement (and ignore) certain commands
instead of failing the request.
- in io_watch_have_data(), no longer g_compress() the entire line.
"polkitagenthelper-pam.c" never backslash escapes the command, it
only escapes the arguments. Of course, there should be no difference
in practice, except that we don't want to handle escape sequences
in the commands.
- in io_watch_have_data(), compare SUCCESS/FAILURE literally.
"polkitagenthelper-pam.c" never appends any trailing garbage to these
commands, and we shouldn't handle that (although "polkitagentsession.c"
does).
- when io_watch_have_data() completes with success, we cannot destroy
AuthRequest right away. It probably still has data pending that we first
need to write to the polkit helper. Wait longer, and let io_watch_can_write()
complete the request.
- ensure we always answer the GDBusMethodInvocation. Otherwise, it gets
leaked.
- use NMStrBuf instead of GString.
We cannot just swallow EAGAIN and pretend that not bytes were read.
read() returning zero means end of file. The caller needs to distinguish
between end of file and EAGAIN.
NMStrBuf is not an opaque structure, so that we can allocate it on the
stack or embed it in a struct.
But most of the fields should not be touched outside of the
implementation.
Also, "len" and "allocated" fields may be accessed directly, but
they should not be modified.
Rename the fields to make that clearer.
We cannot actually mark the field as const, because then you could no
longer initialize a variable that contains a NMStrBuf with designated
initializers.
We also want to keep the "_allocated" alias, for the only places that
are allowed to mutate the field: inside "nm-str-buf.h". Add an alias
for that field, that is allowed to be read, provided that you don't
modify it!
The alternative would be a nm_str_buf_get_allocated() accessor, but
that seems unnecessarily verbose when you could just access the field.
Before, if a struct had a field of type NMStrBuf (which is sensible to do),
then you could not longer initialize the entire struct with
*ptr = (Type) { };
because NMStrBuf contained const fields.
The user should never set these fields directly and use nm_str_buf_*() to modify
them them. But no longer mark them as const, because that breaks valid
use cases.
The allocated buffes are not known to be written. It is unnecessary to
clear them.
If the user writes sensitive data to those locations, without using
the NMStrBuf API, then it is up to the user to bzero the memory
accordingly.
When we have a buffer that we want to grow exponentially with
nm_utils_get_next_realloc_size(), then there are certain buffer
sizes that are better suited.
For example, if you have an empty NMStrBuf (len == 0), and you
want to allocate roughly one kilobyte, then 1024 is a bad choice,
because nm_utils_get_next_realloc_size() will give you 2024 bytes.
NM_UTILS_GET_NEXT_REALLOC_SIZE_1000 might be better in this case.
