Usually, this "<allow send_destination="..."/>" part is shipped
by firewalld's D-Bus policy. However, if firewalld is initially
not installed with NetworkManager already running, dbus-daemon
seems to cache the missing permission for the D-Bus connection.
As a result, when installing and starting firewalld, NetworkManager
requests fail until restart:
firewall: [0x7f4b83643890,change:"eth1"]: complete: request failed (Rejected send message, 1 matched rules; type="method_call", sender=":1.3" (uid=0 pid=715 comm="/usr/sbin/NetworkManager --no-daemon ") interface="org.fedoraproject.FirewallD1.zone" member="changeZone" error name="(unset)" requested_reply="0" destination=":1.25" (uid=0 pid=1243 comm="/usr/bin/python -Es /usr/sbin/firewalld --nofork -"))
https://bugzilla.redhat.com/show_bug.cgi?id=1436770
(cherry picked from commit cc1d409ba8)
It does more than intended; apart from denying messages to that particular
interface it also denies all messages non-qualified with an
interface globally.
This blocks messages completely unrelated to wpa_supplicant, such as
NetworkManager communication with the VPN plugins.
From the dbus-daemon manual:
Be careful with send_interface/receive_interface, because the
interface field in messages is optional. In particular, do NOT
specify <deny send_interface="org.foo.Bar"/>! This will cause
no-interface messages to be blocked for all services, which is
almost certainly not what you intended. Always use rules of the form:
<deny send_interface="org.foo.Bar" send_destination="org.foo.Service"/>
We can just safely remove those rules, since we're sufficiently protected
by the send_destination matches and method calls are disallowed by default
anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=763880
NMExportedObject now derives from GDBusObjectSkeleton, which is what
GDBusObjectManagerServer wants. The main GDBusConnection and each
private server connection now gets a new GDBusObjectManagerServer,
and exported objects are registered with that instead of individually
exporting each GDBusInterfaceSkeleton.
Previously exported objects were not referenced by the BusManager,
but instead removed from the exports hash via weak references. The
GDBusObjectManagerServer instead references exported objects, which
can make them live much longer than they did before.
Co-Authored-By: Thomas Haller <thaller@redhat.com>
It does more than intended; apart from denying messages to that particular
interface it also denies all messages non-qualified with an interface globally.
From the dbus-daemon manual:
Be careful with send_interface/receive_interface, because the
interface field in messages is optional. In particular, do NOT
specify <deny send_interface="org.foo.Bar"/>! This will cause
no-interface messages to be blocked for all services, which is almost
certainly not what you intended. Always use rules of the form: <deny
send_interface="org.foo.Bar" send_destination="org.foo.Service"/>
We can just safely remove those rules, since we're sufficiently protected
by the send_destination matches and method calls are disallowed by default
anyway.
D-Bus default limit of replies per connection has been lowered to 128 due to
CVE-2014-3638, see:
http://cgit.freedesktop.org/dbus/dbus/commit/?id=5bc7f9519ebc6117ba300c704794b36b87c2194bhttps://bugs.freedesktop.org/show_bug.cgi?id=81053
The limit seems to be too low and causes problems in libnm-glib, that will not
return all NetworkManager connection profiles if there are too many of them
(roughly more than the limit). As a consequence, libnm-glib based clients will
not work properly.
Lets increase the limit in our D-Bus org.freedesktop.NetworkManager.conf
configuration as we had it before.
See also older commit d5b31d55fa that did the
opposite thing (removing the limit because the default D-Bus limit was 8192 at
that time).
Of special note is the new D-Bus rule to allow root to talk to
org.freedesktop.NetworkManager.VPN.Plugin, without which NetworkManager
would not hear signals from the VPN plugins. Oddly, this worked
fine with dbus-glib...
https://bugzilla.gnome.org/show_bug.cgi?id=745307
at_console permissions as implemented by D-Bus have some problems:
1) it is now fully redundant with PolicyKit and session tracking via
systemd/ConsoleKit
2) it uses a different mechanism than PolicyKit or systemd to determine
sessions and whether the user is on local or not (pam_console)
3) it was never widely implemented across so removing it
harmonizes D-Bus permissions on all supported distros
To that end, remove the at_console section of the D-Bus permissions,
and rely on session-tracking and PolicyKit to ensure operations are
locked down.
No changes are being made to PolicyKit or session-tracking, so any
operations denied by those mechanisms are still denied, and no
permissions are being relaxed. Instead, this should allow remote
users who log in via remote desktop or SSH to inspect network state,
change connection parameters, and start/stop interfaces. Obviously
if you are remote, you should not touch the interface which your
connection is using, but that concern shouldn't prevent all the other
nice stuff that you can do with NM.
https://bugzilla.gnome.org/show_bug.cgi?id=707983https://bugzilla.redhat.com/show_bug.cgi?id=979416
