- Feb 08, 2018
-
-
Simon McVittie authored
Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by: Simon McVittie <smcv@collabora.com>
-
There’s no need to escape closing brackets if the paired opening bracket is escaped (or doesn’t need escaping). See https://github.com/projectmallard/mallard-ducktype/issues/16#issuecomment-362590519 . Signed-off-by: Philip Withnall <withnall@endlessm.com> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104925 Reviewed-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by: Simon McVittie <smcv@collabora.com>
-
- Feb 06, 2018
-
-
Simon McVittie authored
Based on code contributed by Manish Narang. This is not included in the automated test suite, because it isn't reliable on heavily-loaded automatic test infrastructure like Travis-CI. Reviewed-by: Philip Withnall <withnall@endlessm.com> [smcv: Add the test to the CMake build system too, as requested] [smcv: Convert into a manual test] Signed-off-by: Simon McVittie <smcv@collabora.com> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=102839
-
Simon McVittie authored
DBusLoop isn't thread-safe, so we can't use it to test multi-threaded situations. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=102839 Signed-off-by: Simon McVittie <smcv@collabora.com> Reviewed-by: Philip Withnall <withnall@endlessm.com>
-
Simon McVittie authored
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=102839 Signed-off-by: Simon McVittie <smcv@collabora.com> Reviewed-by: Philip Withnall <withnall@endlessm.com>
-
If one thread is blocking on a pending call, and another thread is dispatching the connection, then we need them to agree on the value of the completed flag by protecting all accesses with a lock. Reads for this member seem to have the connection lock already, so it's sufficient to make sure that the only write also happens under the connection lock. We already set the completed flag before calling the callback, so it seems OK to stretch it to meaning that some thread has merely *taken responsibility for* calling the callback. The completed flag shares a bitfield with timeout_added, but that flag is protected by the connection lock already. Based on suggestions from Simon McVittie on <https://bugs.freedesktop.org/show_bug.cgi?id=102839>. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=102839 [smcv: Revert indentation changes; add commit message] Reviewed-by: Simon McVittie <smcv@collabora.com>
-
If a pending call is provided, _dbus_connection_do_iteration_unlocked checks whether it has completed or has a reply ready as soon as it acquires the I/O path. If that's the case, then the iteration terminates without trying to carry out I/O, so that the pending call can be dispatched immediately, without blocking until a timeout is reached. This change is believed to be necessary, but not sufficient, to resolve #102839. Based on part of a patch from Michael Searle on <https://bugs.freedesktop.org/show_bug.cgi?id=102839>. Commit message added by Simon McVittie. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=102839 Reviewed-by: Simon McVittie <smcv@collabora.com>
-
- Feb 01, 2018
-
-
Simon McVittie authored
Signed-off-by: Simon McVittie <smcv@collabora.com>
-
- Jan 30, 2018
-
-
Simon McVittie authored
Signed-off-by: Simon McVittie <smcv@collabora.com>
-
- Jan 29, 2018
-
-
Simon McVittie authored
Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by: Simon McVittie <smcv@collabora.com>
-
- Jan 16, 2018
-
-
Simon McVittie authored
Coverity CID 253543. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104588 Signed-off-by: Simon McVittie <smcv@collabora.com> Reviewed-by: Philip Withnall <withnall@endlessm.com>
-
- Jan 15, 2018
-
-
Simon McVittie authored
Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This file is the Unix counterpart of dbus-spawn-win.c, so it's less confusing for it to have an indicative name. Signed-off-by: Simon McVittie <smcv@collabora.com> Reviewed-by: Philip Withnall <withnall@endlessm.com> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104588
-
Simon McVittie authored
Otherwise the pre-commit hook won't let me rename it. Signed-off-by: Simon McVittie <smcv@collabora.com> Reviewed-by: Philip Withnall <withnall@endlessm.com> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104588
-
Simon McVittie authored
dbus-spawn.c and dbus-userdb* don't have obviously-Unix-specific names, but are Unix-specific anyway. Signed-off-by: Simon McVittie <smcv@collabora.com> Reviewed-by: Philip Withnall <withnall@endlessm.com> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104588
-
Simon McVittie authored
Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by: Simon McVittie <smcv@collabora.com> Reviewed-by: Philip Withnall <withnall@endlessm.com> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104588
-
Simon McVittie authored
Signed-off-by: Simon McVittie <smcv@collabora.com> Reviewed-by: Philip Withnall <withnall@endlessm.com> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104588
-
Simon McVittie authored
Previously, USERID_HEX and USERNAME_HEX were both replaced by the hex encoding of the numeric uid, something like 31303030 for "1000". Now USERNAME_HEX is something like 736d6376 for "smcv". This is only supported on Unix, but no authentication mechanisms use usernames on Windows anyway. This would require changing the tests that make use of USERNAME_HEX if we had any, but we currently don't. Signed-off-by: Simon McVittie <smcv@collabora.com> Reviewed-by: Philip Withnall <withnall@endlessm.com> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104588
-
Simon McVittie authored
In the well-known system dbus-daemon, it's desirable to avoid looking up non-numeric authorization identities in the user database, because that could deadlock with NSS modules that directly or indirectly require the system bus. Add a flag for whether the username will be looked up in the userdb, and don't set that flag for EXTERNAL auth (which is what we use on the system bus, and on the session bus if not configured otherwise). DBUS_COOKIE_SHA1 authentication is documented in terms of the username (although in fact libdbus sends a numeric uid there too, and GDBus only accepts a numeric uid) so continue to use the userdb for that mechanism. DBUS_COOKIE_SHA1 needs to use the userdb on Unix anyway, otherwise it won't find the user's home directory. Signed-off-by: Simon McVittie <smcv@collabora.com> Reviewed-by: Philip Withnall <withnall@endlessm.com> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104588
-
Simon McVittie authored
While I'm changing its signature anyway, I might as well fix a long-standing FIXME. Signed-off-by: Simon McVittie <smcv@collabora.com> Reviewed-by: Philip Withnall <withnall@endlessm.com> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104588
-
Simon McVittie authored
The very common case for this function is that during AUTH EXTERNAL, it receives a Unix uid encoded as an ASCII decimal integer. There is no need to look up such uids in the system's user database (/etc/password or NSS) when the only information we are going to use from the DBusUserInfo struct is the uid anyway. This avoids taking the lock and performing a potentially time-consuming NSS lookup. This changes behaviour in one corner case: if a privileged process has used one of the set*uid family of functions to set its effective uid to a numeric uid that does not exist in the system's user database, we would previously fail. Now, we succeed anyway: it is true to say in the DBusCredentials that the process has uid 12345, even if uid 12345 does not correspond to any named user. Signed-off-by: Simon McVittie <smcv@collabora.com> Reviewed-by: Philip Withnall <withnall@endlessm.com> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104588
-
Simon McVittie authored
This provides the necessary information for services to make an informed decision about how far they should trust the container type, name and metadata fields. Signed-off-by: Simon McVittie <smcv@collabora.com> Reviewed-by: Philip Withnall <withnall@endlessm.com> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104610
-
Simon McVittie authored
Signed-off-by: Simon McVittie <smcv@collabora.com> Reviewed-by: Philip Withnall <withnall@endlessm.com> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104610
-
Simon McVittie authored
On the session bus, the container type and name might be uncontroversial, but on the system bus, it's questionable how far they can be trusted: they're supplied by the initiator of the per-container server, so we only have their word for it. While we think about what to do about this, remove them, leaving only the instance (which can be used to look up the rest). Signed-off-by: Simon McVittie <smcv@collabora.com> Reviewed-by: Philip Withnall <withnall@endlessm.com> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104610
-
Simon McVittie authored
On the session bus, the container type and name might be uncontroversial, but on the system bus, it's questionable how far they can be trusted: they're supplied by the initiator of the per-container server, so we only have their word for it. Signed-off-by: Simon McVittie <smcv@collabora.com> Reviewed-by: Philip Withnall <withnall@endlessm.com> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104610
-
- Jan 11, 2018
-
-
Simon McVittie authored
Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100317 Reviewed-by: Philip Withnall <withnall@endlessm.com> Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100317 Reviewed-by: Philip Withnall <withnall@endlessm.com> Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100317 Reviewed-by: Philip Withnall <withnall@endlessm.com> Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100317 Reviewed-by: Philip Withnall <withnall@endlessm.com> Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100317 Reviewed-by: Philip Withnall <withnall@endlessm.com> Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100317 Reviewed-by: Philip Withnall <withnall@endlessm.com> Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by: Simon McVittie <smcv@collabora.com> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100317 Reviewed-by: Philip Withnall <withnall@endlessm.com> Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This is an interpretation of the existing text. There are two plausible ways a relaying server could interpret "must ignore [new] fields": it could pass them through as-is, or it could delete them before relaying. Until now, the reference implementation has done the former. However, this behaviour is difficult to defend. If a server relays messages without filtering out header fields that it doesn't understand, then a client can't know whether the header field was supplied by the server, or whether it was supplied by a (possibly malicious) fellow client. We can't introduce useful round-trip-reducing header fields like SENDER_UNIX_USER_ID or SENDER_LINUX_SECURITY_LABEL until the message bus filters them out, *and* provides a way for clients to know for sure that it has done so. This is a step towards that feature. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100317 Reviewed-by: Philip Withnall <withnall@endlessm.com> Signed-off-by: Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
The Telepathy "Tubes" APIs are an example of a server that is not a message bus, but makes use of the sender and destination fields to provide broadly unique-connection-name-like semantics. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100317 Reviewed-by: Philip Withnall <withnall@endlessm.com> Signed-off-by: Simon McVittie <smcv@collabora.com>
-