Commit 4c7fa8dfdc ("core: drop root requirement for
load_connection(s)/set_logging D-Bus calls") removed the enforcing of
permission in the daemon for such methods since the D-Bus daemon
configuration already does that. That change also allows clients to
send a request and not wait for a response, since we don't have to
check the caller credentials in the daemon.
In the future we might switch to polkit for these methods, breaking
clients that don't wait for a reponse, so it seems better to prevent
from beginning such behavior.
Fixes: 4c7fa8dfdc
(cherry picked from commit dd27b79c4e)
Commit 4c7fa8dfdc ("core: drop root requirement for
load_connection(s)/set_logging D-Bus calls") removed the enforcing of
permission in the daemon for such methods since the D-Bus daemon
configuration already does that. That change also allows clients to
send a request and not wait for a response, since we don't have to
check the caller credentials in the daemon.
In the future we might switch to polkit for these methods, breaking
clients that don't wait for a reponse, so it seems better to prevent
from beginning such behavior.
Fixes: 4c7fa8dfdc
The VPN data comes from an external source, it may be bogus.
Default-routes are not allowed on this point and would trigger
an assertion afterwards. Skip over them.
(cherry picked from commit 071103b172)
We need an ifindex for the NMIP4Config/NMIP6Config instance.
For interface-less VPN types, we need to lookup the parent
device, as already done for IPv4.
Fix IPv6 case too.
https://bugzilla.redhat.com/show_bug.cgi?id=1368354
(cherry picked from commit 2da35ddfe8)
The VPN data comes from an external source, it may be bogus.
Default-routes are not allowed on this point and would trigger
an assertion afterwards. Skip over them.
We need an ifindex for the NMIP4Config/NMIP6Config instance.
For interface-less VPN types, we need to lookup the parent
device, as already done for IPv4.
Fix IPv6 case too.
https://bugzilla.redhat.com/show_bug.cgi?id=1368354
When activating a connection, it may fail with nmcli reporting:
$ nmcli connection up id "Wired Connection 1"
Error: Connection activation failed: Active connection removed before it was initialized
This should be easily reproducible by having a connection "Wired Connection 1" with
cloned-mac-address set to random. When the connection is already active on a device,
re-activating with
$ nmcli connection up id "Wired Connection 1"
fails.
We first create a queued-activation and tear down the existing
connection:
device (enp0s25): state change: deactivating -> disconnected (reason 'new-activation')
Shortly after we see:
device[0x557d02cdb0c0] (enp0s25): set-hw-addr: setting MAC address to 'AA:BB:CC:DD:EE:FF' (reset, deactivate)...
device[0x557d02cdb0c0] (enp0s25): taking down device
later, we get:
device (enp0s25): link disconnected
device[0x557d02cdb0c0] (enp0s25): queued state change to unavailable due to carrier-changed (id 17290)
in the meantime, the queued activation request starts:
device (enp0s25): Activation: starting connection 'my-wired' (ca058ec5-8a47-4e1e-b38e-962b71c4699e)
but the device already transitions to unavailable
device[0x557d02cdb0c0] (enp0s25): running queued state change to unavailable (id 17290)
device (enp0s25): state change: disconnected -> unavailable (reason 'carrier-changed') [30 20 40]
which kills the new activation request:
active-connection[0x557d02c10e40]: set state deactivated (was unknown)
Just delay a carrier-lost handling if we have any queued activation
requests.
(cherry picked from commit d4e9b30320)
When activating a connection, it may fail with nmcli reporting:
$ nmcli connection up id "Wired Connection 1"
Error: Connection activation failed: Active connection removed before it was initialized
This should be easily reproducible by having a connection "Wired Connection 1" with
cloned-mac-address set to random. When the connection is already active on a device,
re-activating with
$ nmcli connection up id "Wired Connection 1"
fails.
We first create a queued-activation and tear down the existing
connection:
device (enp0s25): state change: deactivating -> disconnected (reason 'new-activation')
Shortly after we see:
device[0x557d02cdb0c0] (enp0s25): set-hw-addr: setting MAC address to 'AA:BB:CC:DD:EE:FF' (reset, deactivate)...
device[0x557d02cdb0c0] (enp0s25): taking down device
later, we get:
device (enp0s25): link disconnected
device[0x557d02cdb0c0] (enp0s25): queued state change to unavailable due to carrier-changed (id 17290)
in the meantime, the queued activation request starts:
device (enp0s25): Activation: starting connection 'my-wired' (ca058ec5-8a47-4e1e-b38e-962b71c4699e)
but the device already transitions to unavailable
device[0x557d02cdb0c0] (enp0s25): running queued state change to unavailable (id 17290)
device (enp0s25): state change: disconnected -> unavailable (reason 'carrier-changed') [30 20 40]
which kills the new activation request:
active-connection[0x557d02c10e40]: set state deactivated (was unknown)
Just delay a carrier-lost handling if we have any queued activation
requests.
These logging lines are already disabled by default as _LOGt()
is a NOP unless configured --with-more-logging.
However, the logging is still very verbose also for debug-builds
and currently there are no known issues there. Disable the logging
statements (but leave them in so they can easily be enabled).
(cherry picked from commit 4cb845558e)
These logging lines are already disabled by default as _LOGt()
is a NOP unless configured --with-more-logging.
However, the logging is still very verbose also for debug-builds
and currently there are no known issues there. Disable the logging
statements (but leave them in so they can easily be enabled).
The error returned to users when a load_connection(s)/set_logging call
fails due to D-Bus policy denial is a bit obscure:
$ nmcli general logging level debug
Error: failed to set logging: Rejected send message, 4 matched rules;
type="method_call", sender=":1.233" (uid=1001 pid=27225 comm="nmcli
general logging level debug ")
interface="org.freedesktop.NetworkManager" member="SetLogging" error
name="(unset)" requested_reply="0" destination=":1.207" (uid=0
pid=25793 comm="/usr/sbin/NetworkManager --no-daemon ")
Convert it to a more comprehensible:
$ nmcli general logging level debug
Error: failed to set logging: access denied
https://bugzilla.redhat.com/show_bug.cgi?id=1362542
(cherry picked from commit 805925f9ef)
The D-Bus configuration already ensures that only root can do that;
enforcing the permission at policy level seems better than doing it in
the daemon itself because it allows users to change the policy and
also because callers can exit immediately after issuing the request.
(cherry picked from commit 4c7fa8dfdc)
The error returned to users when a load_connection(s)/set_logging call
fails due to D-Bus policy denial is a bit obscure:
$ nmcli general logging level debug
Error: failed to set logging: Rejected send message, 4 matched rules;
type="method_call", sender=":1.233" (uid=1001 pid=27225 comm="nmcli
general logging level debug ")
interface="org.freedesktop.NetworkManager" member="SetLogging" error
name="(unset)" requested_reply="0" destination=":1.207" (uid=0
pid=25793 comm="/usr/sbin/NetworkManager --no-daemon ")
Convert it to a more comprehensible:
$ nmcli general logging level debug
Error: failed to set logging: access denied
https://bugzilla.redhat.com/show_bug.cgi?id=1362542
The D-Bus configuration already ensures that only root can do that;
enforcing the permission at policy level seems better than doing it in
the daemon itself because it allows users to change the policy and
also because callers can exit immediately after issuing the request.
When a assumed software device is brought down externally, it becomes
UNMANAGED_EXTERNAL_DOWN and its state goes from ACTIVATED directly to
UNMANAGED. In such case, we shouldn't flush the IP configuration
(addresses and routes) present on the device.
To fix this, clean up the device with CLEANUP_TYPE_KEEP and modify
nm_device_cleanup() not to flush addresses and devices with such flag.
https://bugzilla.redhat.com/show_bug.cgi?id=1363995
(cherry picked from commit 45cd3302dc)
When a assumed software device is brought down externally, it becomes
UNMANAGED_EXTERNAL_DOWN and its state goes from ACTIVATED directly to
UNMANAGED. In such case, we shouldn't flush the IP configuration
(addresses and routes) present on the device.
To fix this, clean up the device with CLEANUP_TYPE_KEEP and modify
nm_device_cleanup() not to flush addresses and devices with such flag.
https://bugzilla.redhat.com/show_bug.cgi?id=1363995
Previously, we logged also the location (file:line func). nm-logging.c
supported format flags to control the timestamp, the location, and alignment
of the timestamp.
We want that all our logging backends log the same messages. That is,
both syslog and journal should have our ~default~ logging format, that
is with timestamp but without location.
Drop the unused code.
(cherry picked from commit cc828431b8)
Previously, we logged also the location (file:line func). nm-logging.c
supported format flags to control the timestamp, the location, and alignment
of the timestamp.
We want that all our logging backends log the same messages. That is,
both syslog and journal should have our ~default~ logging format, that
is with timestamp but without location.
Drop the unused code.
Even if we know that the new hostname being set is equal to the cached
old one, the user may have manually changed the kernel hostname in the
meanwhile. For example:
# hostname
host123
# hostname localhost
# nmcli connection up eth1
# (now NM receives 'host123' from DHCP, but
# believes it's already set and doesn't update it)
# hostname
localhost
Let's always try to update the kernel (transient) hostname, unless it
is really already set (as returned by gethostname()).
https://bugzilla.redhat.com/show_bug.cgi?id=1356015
(cherry picked from commit 51b2cef04f)
Even if we know that the new hostname being set is equal to the cached
old one, the user may have manually changed the kernel hostname in the
meanwhile. For example:
# hostname
host123
# hostname localhost
# nmcli connection up eth1
# (now NM receives 'host123' from DHCP, but
# believes it's already set and doesn't update it)
# hostname
localhost
Let's always try to update the kernel (transient) hostname, unless it
is really already set (as returned by gethostname()).
https://bugzilla.redhat.com/show_bug.cgi?id=1356015
