GLIB has recently started to officially support the gcc cleanup
attribute in its public API, hence let's do the same for our APIs.
With this patch we'll define an xyz_unrefp() call for each public
xyz_unref() call, to make it easy to use inside a
__attribute__((cleanup())) expression. Then, all code is ported over to
make use of this.
The new calls are also documented in the man pages, with examples how to
use them (well, I only added docs where the _unref() call itself already
had docs, and the examples, only cover sd_bus_unrefp() and
sd_event_unrefp()).
This also renames sd_lldp_free() to sd_lldp_unref(), since that's how we
tend to call our destructors these days.
Note that this defines no public macro that wraps gcc's attribute and
makes it easier to use. While I think it's our duty in the library to
make our stuff easy to use, I figure it's not our duty to make gcc's own
features easy to use on its own. Most likely, client code which wants to
make use of this should define its own:
#define _cleanup_(function) __attribute__((cleanup(function)))
Or similar, to make the gcc feature easier to use.
Making this logic public has the benefit that we can remove three header
files whose only purpose was to define these functions internally.
See #2008.
Clear up how we pass fd owner ship to proxy and bus objects. Document
that ownership is passed of the fds in question even in case of failing
constructors, and that callers should forget about fds pass into the
proxy object.
The alternative would be to duplicate the fds, but given that fds are a
relatively scarce and heavy resource let's better avoid that.
Fixes#1591.
The StartServiceByName() call was provided by dbus-daemon to activate a
service without sending a message. On receiption, dbus-daemon schedules
an activation request (different modes are supported) and sends back the
reply once activation is done.
With kdbus, we marked StartServiceByName() as deprecated. There is no
real reason to start services explicitly. Instead, applications should
just *use* the service and rely on it being activated implicitly.
However, we provide compatibility with dbus-daemon and implement
StartServiceByName() on the proxy via a call to
org.freedesktop.DBus.Peer.Ping() on the destination. This will activate
the peer implicitly as part of the no-op Ping() method call (regardless
whether the peer actually implements that call).
Now, the problem is, StartServiceByName() was synchronous on dbus-daemon
but isn't on bus-proxy. Hence, on return, there is no guarantee that
ListNames includes the activated name. As this is required by some
applications, we need to make this synchronous.
This patch makes the proxy track the Ping() method call and send the
reply of StartServiceByName() only once Ping() returned. We do not look
at possible errors of Ping(), as there is no strict requirement for the
peer to implement org.freedesktop.DBus.Peer. Furthermore, any interesting
error should have already been caught by sd_bus_send() before.
Note:
This race was triggered by gdbus. The gdbus-proxy implementation
relies on a name to be available after StartServiceByName()
returns. This is highly fragile and should be dropped by gdbus.
Even if the call is synchronous, there is no reason whatsoever to
assume the service did not exit-on-idle before ListNames()
returns.
However, this race is much less likely than the startup race, so
we try to be compatible to dbus-daemon now.
Add the PID we are proxying for, as well as the message's sender and
destination string, to the debug message that is printed when the proxy
drops unmatched broadcasts.
The lovely libvirtd goes into crazy mode if it receives broadcasts that
it didn't subscribe to. With bus-proxyd, this might happen in 2 cases:
1) The kernel passes us an unmatched signal due to a false-positive
bloom-match.
2) We generate NameOwnerChanged/NameAcquired/NameLost locally even
though the peer didn't subscribe to it.
dbus-daemon is reliable in what signals it passes on. So make sure we
follow that style. Never ever send a signal to a local peer if it doesn't
match an installed filter of that peer.
sd_bus_flush_close_unref() is a call that simply combines sd_bus_flush()
(which writes all unwritten messages out) + sd_bus_close() (which
terminates the connection, releasing all unread messages) +
sd_bus_unref() (which frees the connection).
The combination of this call is used pretty frequently in systemd tools
right before exiting, and should also be relevant for most external
clients, and is hence useful to cover in a call of its own.
Previously the combination of the three calls was already done in the
_cleanup_bus_close_unref_ macro, but this was only available internally.
Also see #327
Unlike dbus-daemon, the bus-proxy does not know the receiver of a
broadcast (as the kernel has exclusive access on the bus connections).
Hence, and "destination=" matches in dbus1 policies cannot be applied.
But kdbus does not place any restrictions on *SENDING* broadcasts, anyway.
The kernel never returns EPERM to KDBUS_CMD_SEND if KDBUS_MSG_SIGNAL is
set. Instead, receiver policies are checked. Hence, stop checking sender
policies for signals in bus-proxy and leave it up to the kernel.
This fixes some network-manager bus-proxy issues where NM uses weird
dst-based matches against interface-based matches. As we cannot perform
dst-based matches, our bus-proxy cannot properly implement this policy.
If the local peer does not dispatch its incoming queue, the bus-proxy will
slowly fill its outgoing queue. Once its full, it will continously
complain that it cannot forward its messages.
As it turns out, pulseaudio does have an idle background dbus connection
that is not integrated into any mainloop (and given that gdbus and
libdbus1 both support background shared connections, PA is probably not
the only example), therefore, the bus-proxy will loudly complain if it
cannot forward NameOwnerChanged events once the queue is full.
This commit makes the proxy track queue-state and complain only once the
queue runs full, not if it is already full.
A PA bug-report (and patch) has been filed, and other applications should
be fixed similarly. Hence, lets keep the error message, instead of
dropping it. It's unused resources we really want to get rid of, so
silencing the message does not really help (which is actually what
dbus-daemon does).
This patch removes includes that are not used. The removals were found with
include-what-you-use which checks if any of the symbols from a header is
in use.
If we cannot forward messages, include information on the peer and message
just like the xml-policy does. This helps debugging such situations and
figuring out what exactly is going wrong.
UDS sockets transmit EUID+EGID only. Don't try to fake data we don't know!
Otherwise, this might be used to override user-limits by non-root setuid
programs (by faking UID==EUID).
Now that sd-bus is fixed to always use EUID even on UDS, we can safely set
all other UID/GID fields to INVALID.
Sometimes, when we try to reply to messages we don't check return
values. This means we might miss a ECONNRESET, and will get a ENOTCONN
on next command. Treat both the same hence.
Errors like EPERM from the kernel should certainly not be reason to
exit. Let's try to be defensive here, and try to continue on most send
errors, but possibly tell the sender about it.
include-what-you-use automatically does this and it makes finding
unnecessary harder to spot. The only content of poll.h is a include
of sys/poll.h so should be harmless.
Whenever a process performs an action on an object, the kernel uses the
EUID of the process to do permission checks and to apply on any newly
created objects. The UID of a process is only used if someone *ELSE* acts
on the process. That is, the UID of a process defines who owns the
process, the EUID defines what privileges are used by this process when
performing an action.
Process limits, on the other hand, are always applied to the real UID, not
the effective UID. This is, because a process has a user object linked,
which always corresponds to its UID. A process never has a user object
linked for its EUID. Thus, accounting (and limits) is always done on the
real UID.
This commit fixes all sd-bus users to use the EUID when performing
privilege checks and alike. Furthermore, it fixes unix-creds to be parsed
as EUID, not UID (as the kernel always takes the EUID on UDS). Anyone
using UID (eg., to do user-accounting) has to fall back to the EUID as UDS
does not transmit the UID.
Make sure we tell the kernel to fake all UIDs/GIDs. Otherwise, the remote
side has no chance of querying our effective UID (which is usually what
they're interested in).
If we test the policy against multiple destination names, we really should
not print warnings if one of the names results in DENY. Instead, pass the
whole array of names to the policy and let it deal with it.
This implements a shared policy cache with read-write locks. We no longer
parse the XML policy in each thread.
This will allow us to easily implement ReloadConfig().
Move all the proxy code into a "struct Proxy" object that can be used
from multiple binaries.
We now dropped SMACK as we have to refactor it to work properly. We can
introduce it later on.
Daniel Mack