| Age | Commit message (Collapse) | Author |
|---|
|
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).
|
|
GetConnectionCredentials method was added to dbus-1 specification
more than one year ago. This method should return "[...] as many
credentials as possible for the process connected to the server",
but at this moment only "UnixUserID", "LinuxSecurityLabel" and
"ProcessID" are defined by the specification. We should add support
for next credentials after extending dbus-1 spec.
|
|
|
|
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.
|
|
every step
|
|
|
|
After passing the fds over to the sd_bus object, we should forget them,
so that we don't close them a second time when the object goes away.
|
|
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.
|
|
but don't exit
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.
|
|
synthetic_reply_method_return_strv()
That way it matches more closely the nomenclature of our other
success reply calls.
|
|
|
|
|
|
|
|
It's fine to abbreviate local variables, but it's not OK to abbreviate
function names needlessly. This is not an excercise in writing
unreadable code.
|
|
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.
|
|
|
|
Set proper kdbus_cmd_list object size, otherwise:
dbus-send --system --dest=org.freedesktop.DBus --type=method_call \
print-reply / org.freedesktop.DBus.ListQueuedOwners string:org.freedesktop.systemd1
Error org.freedesktop.DBus.Error.InvalidArgs: Invalid argument
|
|
|
|
|
|
Types used for pids and uids in various interfaces are unpredictable.
Too bad.
|
|
While it's a lovely scenario, it's probably not really useful. Fix our
GetConnectionUnixUser() to return the actual 'euid' which we asked for,
not the possible uninitialized 'uid'.
|
|
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).
|
|
We need to implicitly allow HELLO from users with the same uid as the bus.
Fix the bus-uid tracking to use the original uid, not the uid after
privilege-dropping.
|
|
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.
|
|
Make sure to reload our xml policy configuration if requested via the bus.
|
|
Fix whitespace indentation.
|
|
We cannot use "User=" in unit-files if we want to retain privileges. So
make bus-proxy.c explicitly drop privileges. However, only do that if
we're root, as there is no need to drop it on the user-bus.
|
|
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().
|
|
Set thread-names to "p$PIDu$UID" and suffix with '*' if truncated. This
helps debugging bus-proxy issues if we want to figure out which
connections are currently open.
|
|
Instead of using Accept=true and running one proxy for each connection, we
now run one proxy-daemon with a thread per connection. This will enable us
to share resources like policies in the future.
|
|
Now that we want to make bus-proxy multi-threaded, we have to bring back
the systemd-stdio-bridge for our TCP use-cases.
|
|
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.
|
|
Move local and destination bus creation into a helper function. This
further reduces the line count of main().
|
|
Move synthesize_name_acquired() to synthesize.c.
|
|
Move synthesize_*() into synthesize.c and bus_proxy_process_driver() into
driver.c for better code separation.
|
|
The 'at_console' policy-category allows to apply policy-items to clients
depending on whether they're run from within a valid user-session or not.
We use sd_uid_get_seats() to check whether a user has a valid seat (which
excludes remote-sessions like ssh).
|
|
Make sure to print "dbus-1 to kernel" or "kernel to dbus-1" in policy logs
to better diagnose the situation.
|
|
If a dbus-1 client sends a broadcasted signal via the bus-proxy to kdbus,
the bus-proxy has no idea who the receiver is. Classic dbus-daemon has
bus-access and can perform policy checks for each receiver, but we cant.
Instead, we know the kernel will perform receiver policy checks for
broadcasts, so we can skip the policy check and just push it into the
kernel.
This fixes wpa_supplicant which has DENY rules on receive_type=signal for
non-root. As we never know the target, we always DENY all broadcasts from
wpa_supplicant.
Note that will still perform receiver-policy checks for signals that we
get from the kernel back to us. In those cases, we know the receiver
(which is us).
|
|
The policy debug messages swapped "path=" and "interface=", fix this.
|
|
dbus-1 distinguishes expected and non-expected replies. An expected reply
is a reply that is sent as answer to a previously forwarded method-call
before the timeout fires. Those replies are, by default, forwarded and
DENY policy tags are ignored on them (unless explicitly stated otherwise).
We don't track reply-windows in the bus-proxy as the kernel already does
this. Furthermore, the kernel prohibits any non-expected replies (which
breaks dbus-1, but it was an odd feature, anyway).
Therefore, skip policy checks on replies and always let the kernel deal
with it!
To be correct, we should still process DENY tags marked as
send_expected_reply=true (which is *NOT* the default!). However, so far we
don't parse those attributes, and no-one really uses it, so lets not
implement it for now. It's marked as TODO if anyone feels like fixing it.
|
|
|
|
|
|
|
|
to the bus owner should be allowed
Hence, copy this behaviour for bus-proxy too.
|
|
|
|
|
|
Imagine a kdbus peer sending a method-call without EXPECT_REPLY set
through the proxy to a dbus1 peer. The proxy turns the missing
EXPECT_REPLY flag into a dbus1 NO_REPLY_EXPECTED flag. However, if the
receipient ignores that flag (valid dbus1 behavior) and sends a reply, the
proxy will try to forward it to the original peer. This will fail with
EPERM as the kernel didn't track the reply.
We have two options now: Either we ignore EPERM for reply messages, or we
track reply-windows in the proxy so we can properly ignore replies if
EXPECT_REPLY wasn't set.
This commit chose the first option: ignore EPERM for replies. The only
down-side is that replies without matching method call will no longer be
forwarded by the proxy. This works on dbus1, though.
Nobody sane does this, so lets ignore it.
|
