In gcc 8, -Wall -Wextra includes -Wcast-function-type, which warns
about casting a function pointer to an incompatible type. In this
case the cast was because we were ignoring the void * argument, which
in this case is NULL. Since this function is only used within
dbus-message-util.c anyway, we might as well just use the correct
signature and remove the cast.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107349
Reviewed-by: Thiago Macieira <thiago@kde.org>
This is a bit more convenient than fetching it as-needed.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=105656
As this test's coverage expands, this function will have to do more
(clear up name watches, filters, etc.) so it'll be helpful to keep it
all in one place.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=105656
When I introduce per-container message filtering, it'll be useful to
be able to get the instance for a connection without worrying about
whether that connection is NULL (representing the dbus-daemon itself,
or an activatable service that has not yet been activated).
Also make it robust against Containers having not been initialized,
for completeness.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=105656
It isn't completely obvious that connection is allowed to be NULL here.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=105656
This makes it clearer that the only possible error is out-of-memory,
so its use in ListQueuedOwners() is not leaking information to callers
that might not be allowed to know the difference between "doesn't exist"
and "exists but you are not allowed to know that".
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=105656
This connection is the one looking at the name, as opposed to the
one that owns the name (if any).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=105656
It seems I eventually introduce this into every project where I've
added GLib-based unit tests. Today it's dbus' turn.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=105656
For example, this can be the case in bubblewrap or Debian pbuilder after
unsharing the network namespace:
bwrap \
--bind / / \
--dev-bind /dev /dev \
--bind /dev/shm /dev/shm \
--bind /dev/pts /dev/pts \
--unshare-net \
${builddir}/test/test-loopback --tap
...
ok 1 /connect/tcp # SKIP Name resolution does not work here:
getaddrinfo("127.0.0.1", "0", {flags=ADDRCONFIG, family=INET,
socktype=STREAM, protocol=TCP}): Name or service not known
On some systems this can be circumvented by using nss_wrapper from
<https://cwrap.org/nss_wrapper.html>:
cat > hosts <<EOF
127.0.0.1 localhost
EOF
bwrap \
... \
env \
LD_PRELOAD=libnss_wrapper.so \
NSS_WRAPPER_HOSTS=$(pwd)/hosts \
${builddir}/test/test-loopback --tap
...
# listening at tcp:host=127.0.0.1,port=39219,family=ipv4,guid=...
but for systems where that does't work, we should be prepared to skip
the affected tests.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106812
Pathological autobuilder environments might not list localhost in
/etc/hosts.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106812
Minimal autobuilder environments don't always have working TCP,
so we may need to skip TCP tests. Make sure we test the equivalent
code paths via Unix sockets in those environments.
One notable exception is test/fdpass.c, which uses TCP as a transport
that is known not to be able to carry Unix fds; this needs to continue
to use TCP.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106812
This expands test coverage, and lets us reuse the test for other
address schemes.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106812
getaddrinfo and getnameinfo have their own error-handling convention
in which the library call returns either 0 or an EAI_* error code
unrelated to errno. If the error code is not EAI_SYSTEM, then
the value of errno is undefined (in particular it might be carried
over from a previous system call or library call). Introduce a
new helper function _dbus_error_from_gai() to handle this.
The equivalent code paths in Windows appear to be OK: the Windows
implementation of getaddrinfo() is documented to return a Winsock
error code, which we seem to be handling correctly.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106395
nonce-tcp isn't really any more secure than tcp, unless you are
using ANONYMOUS authentication, which should not be considered
secure in any case. Avoid the word "secured" so that people don't
get the wrong idea.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106004
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
This might (?) have made sense behind a firewall in 2003; but now it's
2018, the typical threat model that we are defending against has
changed from "vandals want to feel proud of their l33t skills"
to "organised crime wants your money", and a "trusted" local LAN
probably contains an obsolete phone, tablet, games console or
Internet-of-Things-enabled toaster with remote root exploits.
This make network topologies that used to be acceptable look
increasingly irresponsible.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106004
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
This is the default, and blocks TCP-based attacks by making the
attacker fail to authenticate (while also preventing inadvisable
TCP-based configurations from working).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106004
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
I'm far from convinced that this option should even *exist*, but it
should definitely be documented as a very bad thing.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106004
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106004
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Add a TODO comment as suggested]
Signed-off-by: Simon McVittie <smcv@collabora.com>
With some fairly reasonable threat models (active or passive local
attacker able to eavesdrop on the network link, confidential
information being transferred via D-Bus), secure authentication is
insufficient to make this transport secure: it does not protect
confidentiality or integrity either.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106004
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Like the normal TCP transport, it has no confidentiality or integrity
protection. The only difference is that it adds an extra layer of
authentication.
However, this extra authentication is easily defeated if an attacker
could be eavesdropping on the link between client and server (unlike
DBUS_COOKIE_SHA1, which for all its flaws does at least protect the
confidentiality of the magic cookie).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106004
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
The old version-1 format is deprecated and now produces warnings.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106186
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Add the .devhelp2 file to .gitignore as suggested]
Signed-off-by: Simon McVittie <smcv@collabora.com>
The tutorial is not necessarily a great entry point for the libdbus
documentation: it's infrequently updated, and we should probably have
the "If you use this low-level API directly, you're signing up for some
pain" message from the API reference show up in devhelp more immediately.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106186
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Add longer commit message with rationale]
Signed-off-by: Simon McVittie <smcv@collabora.com>
Newer versions of yelp-build use this instead of a jQuery syntax
highlighter.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106171
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Also add it to .gitignore as suggested]
Signed-off-by: Simon McVittie <smcv@collabora.com>
AddrPC.Offset is the same size as a pointer, but previously
we printed it as though it was the same size as a long,
which is 32 bits on 64-bit Windows.
Reviewed-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=105662
Previously, on 64-bit Windows we were passing a 32-bit int where the
format string expects a 64-bit SOCKET.
Reviewed-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=105662
We weren't sure whether this one should be inherited or not, so I
asked on systemd-devel, and Lennart thought it shouldn't.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104641
Reviewed-by: Philip Withnall <withnall@endlessm.com>
groups is never NULL here, but *groups can be NULL on OOM, and that's the
check that was intended.
Coverity ID 265358.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103737
Reviewed-by: Simon McVittie <smcv@collabora.com>
Specifying a dbus tcp address without a family let dbus-daemon the choice
for listen on ipv4 or ipv6, but did not return the real used ip family,
which is fixed with this commit.
Bug:https://bugs.freedesktop.org/show_bug.cgi?id=105489
Reviewed-by: Simon McVittie <smcv@collabora.com>
Everywhere that we want GLib, we also want GObject and GIO. Detecting
GLib and GIO but not GObject makes very little sense anyway, because
GIO depends on GObject.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=105521
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
The _Must_inspect_result_ annotation is documented to be used in both
the declaration and implementation, but in testing with the MSVC 2012
compiler it appears to be sufficient to use the annotation only in the
declaration to get a compiler warning, as with the GCC compiler.
So the annotation is not necessary in the C implementation.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=105460
[smcv: Rebase dbus-sysdeps.h changes on master]
[smcv: Clarify commit message]
Reviewed-by: Simon McVittie <smcv@collabora.com>
Tested-by: Daniel Wendt <daniel.wendt@linux.com>
