GSocket takes responsibility for closing the fd, and there doesn't
seem to be any way to tell it not to. When this test is adapted to run
under DBusLoop as an alternative to dbus-glib, that becomes a problem,
because DBusLoop/DBusSocketSetEpoll do not tolerate that. Work around it.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68852
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
This function is meaningless (and possibly unimplementable) on Windows.
We shouldn't call it; if we do, it should raise an error.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68852
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
On Windows, the dbus-daemon is not able to fork (daemonize). If someone
explicitly requests forking, it should fail, but if someone
explicitly requests *not* forking, there seems no harm in allowing it.
A few of the regression tests specifically require a dbus-daemon that
will not fork, so allowing this option on Windows means those tests
don't need an extra OS condition.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68852
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
This means we don't need to worry about whether it's thread-safe,
and makes libdbus a little smaller.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68610
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
This function could be accessed from any thread, which would mean it
scribbles on argv twice.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68610
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
If we _dbus_verbose() from more than one thread at the same time,
we don't want to get into trouble with static variables (and I don't
think micro-optimizing this function is really worth it anyway).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68610
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
This reverts commit 83aaa9f359.
This wasn't right: because it looked for a symbol from pthread.h,
modules could end up disagreeing about whether threading was enabled or
not.
Sharing a static variable between threads is not safe in general,
and this function is used in the shared libdbus (for nonce files),
so it can't rely on being single-threaded.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68610
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Assigning to libdbus_1_la_DEPENDENCIES defeats Automake's normal
dependency logic, which makes libdbus-1.la depend on all the
static libraries that will go into it (it still had a corrct dependency
on the other objects, which go through a separate variable).
This meant libdbus-init-win wasn't necessarily built first.
Use EXTRA_libdbus_1_la_DEPENDENCIES to avoid that problem.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68505
Acked-by: Ralf Habacker <ralf.habacker@freenet.de>
dbus_server_disconnect() invokes dbus_server_unref() at the end of
function, the latter will print a trace about server ref count decrease
1. However, it doesn't invoke dbus_server_ref(), so there isn't a trace
about server ref count increase in debug output.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68303
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
At previous, it will do get pid and print a verbose string per inotify
event, and then do send signal to the daemon.
This patch changes the behavior to get pid and print a verbose string
one time.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68303
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
There are a lot of examples in DBus Spec, and some of them just use the
namespace org.freedesktop, and so as object namespace org/freedesktop.
However, this is quite confusing.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=66481
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
DBUS_SESSION_BUS_PID is not mandatory to set, but we should unset it
if present, since it points to a different session's bus. Likewise for
DBUS_SESSION_BUS_WINDOWID.
Similarly, if DBUS_STARTER_BUS_TYPE and DBUS_STARTER_ADDRESS
are set (as they would be under GNOME Terminal 3.8, see
<https://bugs.freedesktop.org/show_bug.cgi?id=63119>) then they
are likely to point to a different session's bus.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39196
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>
It's sufficiently portable that GLib has an equivalent, and I really
don't want to have to either open-code it in dbus-run-session or
link dbus-run-session statically. We have enough statically-linked
rubbish already.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39196
Reviewed-by: Colin Walters <walters@verbum.org>
All mechs do authorization before answering OK/REJECT.
There is no reason to run a second round of authorization which will
return the same answer of the first time (when OK) or will never be
reched (if REJECTed).
Bug: http://bugs.freedesktop.org/show_bug.cgi?id=39720
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Those structs are for DBusTransport internal use, they should not be
referenced outside it.
The transport needs only to allocate memory on initialization and free
it on finalization.
The lifecycle for the two allocated structs is DBusTransport lifecycle
and at DBusTransport's finalization its connection is already
disconnected.
The assumption is that the transport owns a reference for any object the
two structs holds a reference for (particularly DBusConnection)
Bug: http://bugs.freedesktop.org/show_bug.cgi?id=39720
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Now that authorization is in SASL mechs, enable anonymous authorizations
when we are testing anonymous mechs functionality
Bug: http://bugs.freedesktop.org/show_bug.cgi?id=39720
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Also update the authentication script so that DBusAuthorization default
rules are used during testing.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39720
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
