During distcheck, the srcdir is read-only. During "make all", cp may
preserve the read-only status of the file copied from the srcdir,
resulting in failure to overwrite it with an identical file during
"make check" (which depends on all-local).
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

Ralf pointed out that the address doesn't round-trip correctly.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=45896Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Tested-by: Ralf Habacker <ralf.habacker@freenet.de>

Turns out this was duplicated too. We can just use the
platform-independent version, which uses the same code.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=45896Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Tested-by: Ralf Habacker <ralf.habacker@freenet.de>

_dbus_transport_open_socket is called before
_dbus_transport_open_platform_specific, and now handles nonce-tcp, so
this version is no longer useful.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=45896Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Tested-by: Ralf Habacker <ralf.habacker@freenet.de>

Conflicts:
	NEWS
	dbus/dbus-internals.c
	dbus/dbus-mainloop.c
	dbus/dbus-sysdeps-unix.c
	dbus/dbus-sysdeps-win.c
	dbus/dbus-sysdeps.c
	dbus/dbus-sysdeps.h

$(INSTALL) and $(INSTALL_DATA) try to change ownerships to root:bin when
copying tests to builddir. Presumably this is a difference in behaviour
between GNU and BSD install(1): the one in GNU coreutils doesn't try-and-fail
to change ownership if you're not root.

[Commit message added by smcv]

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=48127Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

When libdbus-1 moved to using monotonic time support for the
DBUS_COOKIE_SHA1 authentication was broken, in particular
interoperability with non-libdbus-1 implementations such as GDBus.

The problem is that if monotonic clocks are available in the OS,
_dbus_get_current_time() will not return the number of seconds since
the Epoch so using it for DBUS_COOKIE_SHA1 will violate the D-Bus
specification. If both peers are using libdbus-1 it's not a problem
since both ends will use the wrong time and thus agree. However, if
the other end is another implementation and following the spec it will
not work.

First, we change _dbus_get_current_time() back so it always returns
time since the Epoch and we then rename it _dbus_get_real_time() to
make this clear. We then introduce _dbus_get_monotonic_time() and
carefully make all current users of _dbus_get_current_time() use it,
if applicable. During this audit, one of the callers,
_dbus_generate_uuid(), was currently using monotonic time but it was
decided to make it use real time instead.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=48580

When libdbus-1 moved to using monotonic time support for the
DBUS_COOKIE_SHA1 authentication was broken, in particular
interoperability with non-libdbus-1 implementations such as GDBus.

The problem is that if monotonic clocks are available in the OS,
_dbus_get_current_time() will not return the number of seconds since
the Epoch so using it for DBUS_COOKIE_SHA1 will violate the D-Bus
specification. If both peers are using libdbus-1 it's not a problem
since both ends will use the wrong time and thus agree. However, if
the other end is another implementation and following the spec it will
not work.

First, we change _dbus_get_current_time() back so it always returns
time since the Epoch and we then rename it _dbus_get_real_time() to
make this clear. We then introduce _dbus_get_monotonic_time() and
carefully make all current users of _dbus_get_current_time() use it,
if applicable. During this audit, one of the callers,
_dbus_generate_uuid(), was currently using monotonic time but it was
decided to make it use real time instead.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=48580

It's used by the own_prefix implementation.

Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=46273

Conflicts:
	NEWS
	configure.ac

In mingw-w64 both ESOMETHING and WSASOMETHING are defined,
leading to a duplicate case in the switch.
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=47321

g_thread_init() is deprecated since glib 2.24, call g_type_init() instead.
Bump glib requirement accordingly.

g_thread_create is deprecated since 2.31, use g_thread_new() instead. When
building with a glib earlier than 2.31, provide a backwards compatibility shim.

[Added a comment about why we're using g_type_init() in a test that
doesn't otherwise use GObject -smcv]

[Applied to 1.4 despite just being a deprecation fix because it also fixes
linking with GLib 2.32, in which gthread has been removed from gobject's
Requires and moved to Requires.private, Debian #665665 -smcv]

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=44413
Bug-Debian: http://bugs.debian.org/665665Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

After parsing [allow|deny] rules with own_prefix, check they are enforced
correctly.

https://bugs.freedesktop.org/show_bug.cgi?id=46886

Just check that the parser accept [allow|deny] rules with own_prefix

https://bugs.freedesktop.org/show_bug.cgi?id=46886

https://bugs.freedesktop.org/show_bug.cgi?id=46886

The "unixexec:" transport will create a local AF_UNIX socket with
socketpair(), then fork and execute a binary on one side with STDIN and
STDOUT connected to it and then use the other side.

This is useful to implement D-Bus tunneling schemes, for example to get
a D-Bus connection to the system bus on a different host, similar how
udisks is already doing it. (udisks uses SSH TCP tunneling for this,
which is a bit ugly and less secure than this solution).

Suggested use is with connection strings like the following:

  unixexec:path=ssh,argv1=foobar,argv2=system-bus-bridge

or:

  unixexec:path=pkexec,argv1=system-bus-bridge

or even:

  unixexec:path=sudo,argv1=system-bus-bridge

The first line would execute the binary 'system-bus-bridge' on host
'foobar' and then pass D-Bus traffic to it. This (hypothetical) bridge
binary would then forward the information to the local system bus.

The second and third line use this scheme locally to acquire a
privileged connection through pkexec resp. sudo: instead of connecting
directly to the bus, they use the same bridge binary which will forward
all information to the system bus.

The arguments of the protocol are 'path' for the first execlp()
argument, and argv0, argv1, and so on for the following arguments. argv0
can be left out in which case path will be used.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=35230Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

This is optimized on Linux and enumerates through /proc/self/fd with a
fallback on brute-force closing of fds, in case /proc is not available.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=35230Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

This adds a specification text for the new unixexec: transport.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=35230Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=47076
Bug-Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=675491Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=33840Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>

https://bugs.freedesktop.org/show_bug.cgi?id=46886

https://bugs.freedesktop.org/show_bug.cgi?id=46882

The DBusPipe code was broken by commit 6e214b5b, which switched
from C runtime API to Win32 API for WinCE's benefit. In a DBusPipe,
fd_or_handle is in fact always a C runtime file descriptor, which can't
be used with the Win32 API (which expects a HANDLE).

This commit goes back to the C runtime API. It might cause WinCE support
to regress, but at least dbus-daemon.exe --print-address works again.

This is enough to make a few tests work under Wine when cross-compiling
from Linux to mingw-w64: in particular, this now works:

    DBUS_TEST_DAEMON=bus/dbus-daemon.exe DBUS_TEST_DATA=test/data \
    wine test/test-dbus-daemon.exe -p /echo/session

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=46049Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39549Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39549Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>

dbus_bool_t is the same as dbus_uint32_t, but if we have a separate
bool_val member, it's more obvious that people are getting it right.
It's not called bool because that's a keyword in C++.

int (for file descriptors) doesn't appear in the D-Bus message wire
format, but then again neither does char *, and
dbus_message_iter_get_basic() and friends can return an int (due to
internal index-into-array-of-fds -> fd remapping in libdbus).
In theory int might not be the same size as any of the dbus_intNN_t
types, and anyway it's easier to see that people are getting it right
if we make it explicit.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=11191Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>

In practice, D-Bus bindings end up reinventing DBusBasicValue anyway,
so it might as well be API.

Also stop claiming that all basic-typed values are guaranteed to fit in
8 bytes - this is not true if your platform has more than 8-byte pointers
(I'm not aware of any such platform now, but let's not rule it out).

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=11191Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>