The 'portname' sysfs attribute of s390 devices is deprecated since
kernel 4.4 and always set to 'no portname required'. But even on older
kernels such value must be interpreted as an unset portname and thus
ignored.
https://bugzilla.redhat.com/show_bug.cgi?id=1327204
Having a gateway defined when never-default=yes causes troubles in
connection matching and anyway makes no sense.
If the combination is found, remove the gateway during the
normalization phase.
https://bugzilla.redhat.com/show_bug.cgi?id=1313091
g_file_read_link() "reads" the symbolic link. If it's a relative path,
we get a relative path which is anchored on @file. We must resolve that
to be absolute.
The notification was missing from a long time. The issue has been exposed only
now due to the c57e5a6b66 fix which properly
implemented the "startup-complete" notification substituting out of place code
which masked the bug.
The top-level form was left on screen after exit (this is visible only
on some types of terminal as vt100), breaking automated tests.
Fixes: b2fb80928e
We connect to notify::startup-complete signal of each connection,
but after we signal startup-complete once, we don't need that
signal anymore. Disconnect.
The following settings are effectively identical:
dns=none,rc-manager=*any*
dns=none,rc-manager=unmanaged
dns=default,rc-manager=unmanaged
The new setting is only there for completeness and only
makes sense for a dns plugin.
Already previously, the mode and rc-manager were intertwined in a complicated
way:
- dns=none effectively disables rc-manager.
- if resolv.conf was immutable, it would disable the rc-manager
by setting "resolv_conf_mode=NM_DNS_MANAGER_RESOLV_CONF_UNMANAGED".
- resolv_conf_mode was anyway a redundant piece of information to
rc_manager.
Now there are only two relevant settings: priv->plugin and
priv->rc_manager. And they can be set independently from each other.
Before that was not possible. For example, you could not set a
dns plugin with rc-manager=unmanaged (the only way to achive that
was via an immutable resolv.conf or by having rc-manager=symlink
and let resolv.conf link somewhere else.
The "dns" and "rc-manager" properties are strongly related. Initialize them
together in init_resolv_conf_mode().
One difference is, that we now set rc_manager before setting the mode.
But that shouldn't matter.
We already have "rc-manager=file", rename "rc-manager=none" to "symlink"
because that better describes what it is actually doing. Of course, the
old name is still accepted.
Generate a stable connection UUID for the default-wired-connection.
Otherwise, on every reboot, the UUID changes although the generated
connection is the same.
But also hash into the UUID the machine-id, the device name and the
hardware address. So, the UUID is only the same if the connection is
identical in every aspect.
Also, the UUID is used as Network_ID for the stable-privacy address
generation mode. It is bad to re-create different UUIDs on every boot
as it causes different addresses.
For some device types, we use the DEVTYPE from sysfs to determine the
link type. However, the way we read from sysfs can race with device
renames and we could miss the chance to read DEVTYPE correctly.
This doesn't completely fix the sysfs race, but cures the boot-time race
with systemd renaming the device while we are initializing the link.
We ideally should use GUDev for all sysfs accesses, but that would need
some more work for this particular case as currently we need the link type
before we have an udev device instance.
https://bugzilla.gnome.org/show_bug.cgi?id=764803
Co-Authored-By: Beniamino Galvani <bgalvani@redhat.com>
The daemon does not run with a particular locale of a user. Localizing
makes no sense (at least, we don't do it usually and it would make
logging localized).
As we don't take a reference on @self during the asynchronous
request, we must properly support cancelling in case of early
destruction.
I think, it's gdbus' responsibility not to leak any file descriptors
when cancelling a D-Bus request that returns file descriptors. Thus,
our usual pattern works here too.
libnm-core/nm-vpn-plugin-info.c: In function ‘nm_vpn_plugin_info_get_auth_dialog’:
shared/gsystem-local-alloc.h:53:46: error: ‘prog_basename’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
Fixes: a3f94f451b
When mounting /proc with hidepid, we might fail to read the
start-time of the process from /proc/$PID/stat. In this case,
we should just accept a start-time of zero.
On the other side of authentication, polkit should accept a zero
start-time too.
nm_utils_get_start_time_for_pid() has other uses in NetworkManager,
mostly when killing a process from a PIDFILE or during
nm_utils_kill_process_sync(). In both these cases, this will only
succeed if we try to kill a process that also runs a root.
For processes started by the current instance, we don't care about the
PIDFILE and use nm_utils_kill_child_?sync() -- so there is no problem
with hidepid there.
https://bugzilla.gnome.org/show_bug.cgi?id=764502
