dbus issueshttps://gitlab.freedesktop.org/dbus/dbus/-/issues2018-11-20T17:12:21Zhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/236CMake build should fail if documentation source files are missing2018-11-20T17:12:21ZSimon McVittieCMake build should fail if documentation source files are missingThe following discussion from !48 should be addressed:
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/48#note_80417):
> [A source file not existing] should probably be a build error (the...The following discussion from !48 should be addressed:
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/48#note_80417):
> [A source file not existing] should probably be a build error (the build would fail if any other source file was missing)https://gitlab.freedesktop.org/dbus/dbus/-/issues/235Test for windows autolaunching missing2022-06-27T18:18:54ZRalf HabackerTest for windows autolaunching missingFor more thorough coverage, it would be great if you there is a separate test or tests for Windows autolaunching that demonstrates how it should behave (including the corner cases like different scopes, and including assertions about whe...For more thorough coverage, it would be great if you there is a separate test or tests for Windows autolaunching that demonstrates how it should behave (including the corner cases like different scopes, and including assertions about whether it started a new bus or reused an existing bus).
Followup of https://gitlab.freedesktop.org/dbus/dbus/merge_requests/23#note_80310Ralf HabackerRalf Habackerhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/234user-triggerable dbus-daemon memory leak caused by CVE-2014-3477 fix2019-01-16T12:14:08ZSimon McVittieuser-triggerable dbus-daemon memory leak caused by CVE-2014-3477 fixWhile trying to set up dbus to be able to run tests in AddressSanitizer, I found a memory leak introduced in 2014 when fixing CVE-2014-3477 ([fdo#78979](https://bugs.freedesktop.org/show_bug.cgi?id=78979)). If a caller sends a message to...While trying to set up dbus to be able to run tests in AddressSanitizer, I found a memory leak introduced in 2014 when fixing CVE-2014-3477 ([fdo#78979](https://bugs.freedesktop.org/show_bug.cgi?id=78979)). If a caller sends a message to an activatable service, and the
service gets auto-started, then the dbus-daemon discovers that the caller is not actually allowed to send the message to the service, it will leak one "permission denied" error.
This is technically a system bus denial of service via resource exhaustion, because someone could spam messages that each activate a service, and let the dbus-daemon leak all those errors. However, it's a weak attack with multiple mitigations, so I'm not sure whether we should treat it as a security vulnerability or just an ordinary bug. @thiago, @walters, @rhabacker: opinions?
Mitigations:
- Each denied message is logged to the system log, making it a very noisy attack (and it's obvious which uid and even which process to blame)
- To leak unbounded amounts of memory quickly, an attacker would need an unbounded number of activatable services that they aren't allowed to contact (but in practice there is a finite number of services)
- To leak unbounded amounts of memory slowly, an attacker would need an activatable service, that they aren't allowed to contact, that either: has exit-on-idle behaviour, is remotely crashable, or can otherwise be induced to exit so that it can be reactivated
- If you want to trigger swappy performance death or the OOM killer on a general-purpose Linux system, there are almost certainly easier ways!
No pull request because I don't think we can embargo those, but I'll quote the patch in a comment.https://gitlab.freedesktop.org/dbus/dbus/-/issues/233make doc fails to build manpages2018-11-20T17:13:32ZRalf Habackermake doc fails to build manpagesGenerating xml doc is the default with cmake build system. On running make doc with cmake on linux I get:
```
[ 14%] Built target dbus-update-activation-environment.1
doc/CMakeFiles/dbus-monitor.1.html.dir/build.make:60: *** target patt...Generating xml doc is the default with cmake build system. On running make doc with cmake on linux I get:
```
[ 14%] Built target dbus-update-activation-environment.1
doc/CMakeFiles/dbus-monitor.1.html.dir/build.make:60: *** target pattern contains no '%'. Schluss.
CMakeFiles/Makefile2:2404: recipe for target 'doc/CMakeFiles/dbus-monitor.1.html.dir/all' failed
make[1]: *** [doc/CMakeFiles/dbus-monitor.1.html.dir/all] Error 2
Makefile:162: recipe for target 'all' failed
make: *** [all] Error 2
```https://gitlab.freedesktop.org/dbus/dbus/-/issues/232Consider removing BROKEN_POLL check2018-11-16T15:09:51ZSimon McVittieConsider removing BROKEN_POLL check[From !18](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/18#note_51881):
> > Add cmake check for BROKEN_POLL
>
> I'm not really sure why dbus even has this check - as far as I can see, we're careful to only poll things we can ...[From !18](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/18#note_51881):
> > Add cmake check for BROKEN_POLL
>
> I'm not really sure why dbus even has this check - as far as I can see, we're careful to only poll things we can rely on being able to poll, notably not including devices:
>
> * sockets
> * pipes (Unix only)
> * inotify (Linux and QNX only)
> * kqueue (*BSD only)
>
> I would suggest dropping this commit, and making the CMake build just assume that poll() works. We can consider whether to drop the Autotools check as a separate issue.
This is that separate issue.https://gitlab.freedesktop.org/dbus/dbus/-/issues/231Decide whether we want merge commits when a MR is merged2020-04-27T15:26:22ZSimon McVittieDecide whether we want merge commits when a MR is mergedGitlab has three configurable strategies for merging MRs:
* Fast-forward with linear history. The commits are required to have been rebased on current master before merging (for outdated commits there is a Rebase button in the web UI wh...Gitlab has three configurable strategies for merging MRs:
* Fast-forward with linear history. The commits are required to have been rebased on current master before merging (for outdated commits there is a Rebase button in the web UI which will do this for you, in simple cases where there are no conflicts), and are pushed as-is, without adding any details of the merge request. For example, this is how I merged !8: there is no indication in the commits that it was MR !8, or that David King reviewed it.
* Merge commit with semi-linear history. The commits are required to have been rebased on current master, but then are merged with a non-trivial merge commit. For example, I enabled this before merging dbus/dbus-glib!1: you can see from the commit history that Alan Coopersmith contributed two commits https://gitlab.freedesktop.org/dbus/dbus-glib/commit/c22bbbe9d60bf9404719d3fc5e4be549faef814f and https://gitlab.freedesktop.org/dbus/dbus-glib/commit/a1241eab2e319f09a586a88a928dfa8163780cd2, and when I clicked the Merge button, Gitlab created https://gitlab.freedesktop.org/dbus/dbus-glib/commit/73e32f5aff01bb2915ffbd137d8f0c5ca326367c for me.
* Merge commit with non-linear history. I don't have a concrete example of this in dbus, but you can see it in https://gitlab.gnome.org/GNOME/glib if you examine the history of https://gitlab.gnome.org/GNOME/glib/merge_requests/389: you'll see that https://gitlab.gnome.org/GNOME/glib/commit/6c8b9f31b15bba38c7eb82b17437c1f462fb6ab8 merges a commit that is based on older-than-current code.
Unfortunately, these are chosen globally for a project (e.g. dbus/dbus), and maintainers can't choose which one is the most appropriate at the time they land a merge request.
The advantage of the linear history is that it's simple (one single line of ancestry in gitk/gitg), and very easy to use with `git bisect`. The disadvantage is that we lose details of which merge request resulted in merging a particular change, which means it's harder to find the discussion that led to it being accepted.
The advantages of semi-linear history are that `git bisect` still works well, and we still have details of the merge request.
The advantage of non-linear history is that the commit that gets merged is exactly what the patch submitter tested (although note that if we are concerned about this, we can always ask the patch submitter to rebase and re-test). The disadvantage is that bisecting won't necessarily work at all.
I think semi-linear history is a good compromise position, and I've enabled it in dbus and dbus-glib. Do any of the other maintainers agree or object?
Note that if we want to use a different strategy on a case-by-case basis, maintainers can bypass Gitlab and push directly to master. For stable branches, I'll probably stick to using `git cherry-pick` from master and pushing directly to the stable branch.
/cc @rhabacker @thiago @waltershttps://gitlab.freedesktop.org/dbus/dbus/-/issues/230bus/desktop-file.c: Incorrect logic for excluding invalid group names in is_v...2018-10-18T11:29:31ZRalf Habackerbus/desktop-file.c: Incorrect logic for excluding invalid group names in is_valid_section_name()With recent dbus code from git master branch I get the following compile error with autotools:
```
../../dbus/bus/desktop-file.c: In function ?is_valid_section_name?:
../../dbus/bus/desktop-file.c:385:7: error: logical or of collectivel...With recent dbus code from git master branch I get the following compile error with autotools:
```
../../dbus/bus/desktop-file.c: In function ?is_valid_section_name?:
../../dbus/bus/desktop-file.c:385:7: error: logical or of collectively exhaustive tests is always true [-Werror=logical-op]
if (!((*name >= 'A' && *name <= 'Z') || (*name >= 'a' || *name <= 'z') ||
^
```
As already mentioned in the merge request !15, it turned out that besides the compilation error also the logic is defective and has to be repaired.
https://gitlab.freedesktop.org/dbus/dbus/-/issues/229Follow-up from "Add windows implementation of dbus-run-session helper tool"2018-10-17T08:00:05ZRalf HabackerFollow-up from "Add windows implementation of dbus-run-session helper tool"The following discussions from !7 should be addressed:
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/7#note_50506): (+1 comment)
> Why does a change to dbus-run-session require changing...The following discussions from !7 should be addressed:
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/7#note_50506): (+1 comment)
> Why does a change to dbus-run-session require changing the libraries that are linked into a manual test?
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/7#note_50507):
> Same
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/7#note_50508):
> Same
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/7#note_50509):
> Don't expose this directly. dbus-run-session should call `_dbus_hash_table_unref()` instead - that's already `DBUS_PRIVATE_EXPORT`.
>
> In general, a particular data structure should either be refcounted (has `_ref` and `_unref`, like `DBusHashTable`) or not refcounted (has `_free`, like `DBusString`). A mixture of the two means we got it wrong somewhere.
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/7#note_50510):
> If this is only used in dbus-run-session, I'd prefer to put it in dbus-sysdeps-win-util.c, which means it doesn't need to be `DBUS_PRIVATE_EXPORT` and isn't part of the shared library.
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/7#note_50511):
> Coding style: align pointer stars with the name, not the type, because that's how C precedence works (`char *a, b;` is the same as `char *a; char b;`, but if you write it as `char* a, b` then you might be misled into thinking it's the same as `char *a; char *b;`).
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/7#note_50512): (+1 comment)
> Can we continue to link with `libdbus-1.la` on Unix, and only use `libdbus-internal.la` on Windows?
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/7#note_50513): (+1 comment)
> Coding style: space before open parenthesis
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/7#note_50515): (+3 comments)
> This is a bit of a weird setup; I'll have to look at the old Bugzilla bug to refresh my memory of how we got here.
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/7#note_50516):
> Coding style nitpick: `if (!result)`
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/7#note_50517):
> `server_handle` and `app_handle` could be uninitialized at this point. If I'm remembering correctly that a `HANDLE` is a pointer, use:
>
> ```
> HANDLE server_handle = NULL;
>
> ...
>
> out:
> ...
> if (server_handle != NULL)
> CloseHandle (server_handle);
> ...
> ```
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/7#note_50519):
> `dbus_free` should already be a `DBusFreeFunction`, so you shouldn't need this cast.
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/7#note_50520):
> If you `goto out` after this point, you'll double-free `env`.
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/7#note_50521):
> If you `goto out` early, `env_table` will be uninitialized. Initialize it to `NULL` and only free it if it's non-`NULL`.
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/7#note_50523): (+1 comment)
> Is this relevant to the rest of the commit?
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/merge_requests/7#note_50529): (+1 comment)
> `config_file` defaults to `NULL`, which means "use the standard session bus config file", so this needs to be something like
>
> ```
> if (config_file != NULL)
> _dbus_string_append_printf (&argv_strings[1], "--config-file=%s", config_file);
> else
> _dbus_string_append_printf (&argv_strings[1], "--session");
> ```
>
> to match the Unix implementation.https://gitlab.freedesktop.org/dbus/dbus/-/issues/228-Werror=unused-variable when libX11 is not installed2018-10-18T17:24:56ZSimon McVittie-Werror=unused-variable when libX11 is not installed## Steps to reproduce
* Don't have libX11 development headers (for example `apt remove libx11-dev` on Debian)
* Build dbus with `--enable-developer`
## Expected result
* Successful dbus-launch build (without X11 autolaunch support)
#...## Steps to reproduce
* Don't have libX11 development headers (for example `apt remove libx11-dev` on Debian)
* Build dbus with `--enable-developer`
## Expected result
* Successful dbus-launch build (without X11 autolaunch support)
## Actual result
```
/home/smcv/src/dbus/tools/dbus-launch.c: In function ‘main’:
/home/smcv/src/dbus/tools/dbus-launch.c:849:13: error: unused variable ‘error’ [-Werror=unused-variable]
DBusError error = DBUS_ERROR_INIT;
^~~~~
```Simon McVittieSimon McVittiehttps://gitlab.freedesktop.org/dbus/dbus/-/issues/227Unit tests generate core dumps when built with CMake2021-06-21T07:40:54ZSimon McVittieUnit tests generate core dumps when built with CMake## Steps to reproduce
* Configure dbus with cmake (e.g. `mkdir build; cd build; cmake ../cmake`) on a Linux system with core dumps or `systemd-coredump` enabled
* `make`
* `make check`
## Expected result
* Tests pass
* No core dumps f...## Steps to reproduce
* Configure dbus with cmake (e.g. `mkdir build; cd build; cmake ../cmake`) on a Linux system with core dumps or `systemd-coredump` enabled
* `make`
* `make check`
## Expected result
* Tests pass
* No core dumps found
## Actual result
* Tests pass, slowly
* Many core dumps from `test-segfault`Simon McVittieSimon McVittiehttps://gitlab.freedesktop.org/dbus/dbus/-/issues/225_dbus_get_is_errno_eagain_or_ewouldblock: avoid -Wlogical-op warning2019-04-17T12:38:26ZBugzilla Migration User_dbus_get_is_errno_eagain_or_ewouldblock: avoid -Wlogical-op warning## Submitted by David King
Assigned to **D-Bus Maintainers**
**[Link to original bug (#108345)](https://bugs.freedesktop.org/show_bug.cgi?id=108345)**
## Description
I tried to build dbus from git master on Fedora 29 (with GCC 8.2...## Submitted by David King
Assigned to **D-Bus Maintainers**
**[Link to original bug (#108345)](https://bugs.freedesktop.org/show_bug.cgi?id=108345)**
## Description
I tried to build dbus from git master on Fedora 29 (with GCC 8.2.1), and from running autogen.sh and calling make (not injecting any extra CFLAGS, as far as I know), I get the following warning:
dbus-sysdeps-unix.c: In function ‘_dbus_get_is_errno_eagain_or_ewouldblock’:
dbus-sysdeps-unix.c:4607:22: error: logical ‘or’ of equal expressions [-Werror=logical-op]
return e == EAGAIN || e == EWOULDBLOCK;
errno(3) mentions that EAGAIN and EWOULDBLOCK can be identical, and in this case, they are and the warning is triggered. Working around the warning is quite easy, but complicates the expression.
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/224Missing D-Bus C++ wrapper on wiki page2018-10-12T21:36:24ZBugzilla Migration UserMissing D-Bus C++ wrapper on wiki page## Submitted by Waqar Hameed
Assigned to **D-Bus Maintainers**
**[Link to original bug (#108271)](https://bugs.freedesktop.org/show_bug.cgi?id=108271)**
## Description
Lennart Poettering advised me to file a bug here for the wiki...## Submitted by Waqar Hameed
Assigned to **D-Bus Maintainers**
**[Link to original bug (#108271)](https://bugs.freedesktop.org/show_bug.cgi?id=108271)**
## Description
Lennart Poettering advised me to file a bug here for the wiki page regarding a missing sd-bus C++ wrapper library. Please see the attached mail conversation below:
>> Hi!
>>
>>
>> You have a nice collection of sd-bus wrappers for different
>> languages at
>> https://www.freedesktop.org/wiki/Software/DBusBindings/. I was just
>> wondering if there is any reasons for why you have not included
>> sdbusplus (https://github.com/openbmc/sdbusplus)??
> Consider filing a bug against the dbus project, as that wiki page is
> maintained as part of that.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
Thank you!https://gitlab.freedesktop.org/dbus/dbus/-/issues/223Move more test code to test/2019-01-21T15:48:13ZBugzilla Migration UserMove more test code to test/## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#108178)](https://bugs.freedesktop.org/show_bug.cgi?id=108178)**
## Description
dbus currently has too much test code in bus/ and dbus/. This i...## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#108178)](https://bugs.freedesktop.org/show_bug.cgi?id=108178)**
## Description
dbus currently has too much test code in bus/ and dbus/. This is awkward for several reasons:
* we need to compile the test binaries alongside the rest of bus/ and dbus/, but then run them from test/
* the test code gets counted as part of bus/ and dbus/ when computing coverage statistics, distorting our ideas about the coverage of the actual production code
* the "embedded tests" should not be compiled into libdbus and dbus-daemon when building secure, efficient production dbus binaries, but then we lose test coverage by disabling them
* the test framework used for the "embedded tests" makes it hard to skip tests that take forever and might not even be relevant to the bug/feature you're actually working on
This branch attempts to clean that up, removing something like half of the test code from dbus/, along with all the test executables.
Because I'm experimenting with freedesktop.org Gitlab ahead of dbus' migration, here's a merge request to review: https://gitlab.freedesktop.org/smcv/dbus-temp/merge_requests/2
(That's in a temporary clone of dbus, which I'll archive when we have the real dbus/dbus.git in Gitlab, and replace with a proper fork in smcv/dbus.)
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/222Extra whitespace in comm= field2018-11-01T12:07:23ZBugzilla Migration UserExtra whitespace in comm= field## Submitted by Laurent Bigonville
Assigned to **D-Bus Maintainers**
**[Link to original bug (#107887)](https://bugs.freedesktop.org/show_bug.cgi?id=107887)**
## Description
Hi,
It seems that in the log the comm= field contain an...## Submitted by Laurent Bigonville
Assigned to **D-Bus Maintainers**
**[Link to original bug (#107887)](https://bugs.freedesktop.org/show_bug.cgi?id=107887)**
## Description
Hi,
It seems that in the log the comm= field contain an extra whitespace at the end:
"dbus-daemon[23494]: [session uid=1000 pid=23494] Connection :1.0 (uid=1000 pid=23495 comm="dbus-monitor " label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023") became a monitor."
Looking at the code, it seems that _dbus_command_for_pid() is at fault here. /proc/`<pid>`/cmdline also contain a final \0 which is translated to a whitespace, this one should probably be stripped?
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/221invalid example in specification2018-12-03T15:29:41ZBugzilla Migration Userinvalid example in specification## Submitted by Peter A. Bigot
Assigned to **D-Bus Maintainers**
**[Link to original bug (#107685)](https://bugs.freedesktop.org/show_bug.cgi?id=107685)**
## Description
The section on ObjectManager suggests the following match ru...## Submitted by Peter A. Bigot
Assigned to **D-Bus Maintainers**
**[Link to original bug (#107685)](https://bugs.freedesktop.org/show_bug.cgi?id=107685)**
## Description
The section on ObjectManager suggests the following match rule for a trivial client:
"type='signal',name='org.example.App2',path_namespace='/org/example/App2'"
The section on Match Rules does not admit "name" as a valid key.
Maybe "sender" was meant?
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/220--enable-relocation support breaks assumptions made by mingw32-install-post.sh2018-11-15T13:29:45ZBugzilla Migration User--enable-relocation support breaks assumptions made by mingw32-install-post.sh## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#107662)](https://bugs.freedesktop.org/show_bug.cgi?id=107662)**
## Description
Created attachment 141245
fix-order-of-dbus-1.pc...## Submitted by Ralf Habacker `@rhabacker`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#107662)](https://bugs.freedesktop.org/show_bug.cgi?id=107662)**
## Description
Created attachment 141245
fix-order-of-dbus-1.pc.patch
Cross building dbus from git master with autotools for windows fails because of two issues
1.cross pkg-config 0.28 is confused to not have prefix= in the first line of dbus-1.pc
2. relocation support in configure.ac does not recognize --exec_prefix expanded to ${prefix} and --libdir to ${prefix}/lib
For both issues a related patch has been appended.
~~**Patch 141245**~~, "fix-order-of-dbus-1.pc.patch":
[fix-order-of-dbus-1.pc.patch](/uploads/711e79dd42873d93b2ef29685083b6b4/fix-order-of-dbus-1.pc.patch)
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/219[RFC] specification extension: ConnectClient()2018-10-15T13:17:34ZBugzilla Migration User[RFC] specification extension: ConnectClient()## Submitted by Tom Gundersen `@tomegun`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#107245)](https://bugs.freedesktop.org/show_bug.cgi?id=107245)**
## Description
This is a follow-up on the discussion in <https://...## Submitted by Tom Gundersen `@tomegun`
Assigned to **D-Bus Maintainers**
**[Link to original bug (#107245)](https://bugs.freedesktop.org/show_bug.cgi?id=107245)**
## Description
This is a follow-up on the discussion in <https://github.com/systemd/systemd/issues/9503>.
I want to suggest adding a new call, ConnectClient() to the org.freedesktop.DBus interface. The intention behind this is to allow a (privileged) client to connect and claim names on behalf of another (unprivileged) one.
The discussion that precipitated this was the desire to allow PID1 to spawn dbus-clients running as a dynamic user, without having to update the DBus policy dynamically to allow these new users to connect and claim names on the bus.
The proposed API extension would allow PID1 to tell dbus daemon to connect the new client, acquire for it a set of given names, and pin in it its dynamic (unprivileged) credentials, but to use PID1's (privileged) credentials for the policy checks when deciding if the client is allowed to be connected and to acquire the names.
This would solve the immediate problem at hand of dynamic users, but it would also allow other features:
1) Scheduling of well-known names
Currently, if a name is activatable, it is always activatable. There is no way of delaying the availability of a name, or making a name no longer activatable. Short of delaynig the start-up of the whole bus, or shutting the bus down.
2) Socket activation of DBus clients
Allowing DBus clients to be socket-activated is both a simpler scheme than the current name activation, but it would also allow for proper exit-on-idle, which name activation does not allow (without potentially dropping messages).
3) Simplification of XML policy
This is obviously up to the implementers, but this scheme would long-term allow systems without own/user/group directives. And as send_* recv_* directives are already not strictly speaking necessary (one could use polkit instead), this could in the future allow for greatly simplified policies in the common case.
Suggested API (based on suggestion by David Herrmann):
`org.freedesktop.DBus.ConnectClient(h socket, a{sv} args) -> (s unique_name);
This pre-connects, pre-authenticates, and prepares an AF_UNIX socket for use as a D-Bus connection. The socket is taken as input rather than output, to guarantee that the owning-uid/creds are correct. If the socket is not AF_UNIX+SOCK_STREAM+unconnected, the call simply fails.
The args parameter can be extended in the future to modify this call. Examples:
`RequestNames`: Takes a string array as argument; specifies which names are pre-acquired by the client.
`AllowUnixFds`: Set the ALLOW_UNIX_FDS flag for the new connection.
The message daemon makes this call available to everyone, but verifies the caller (not the passed in client socket) is allowed to connect and claim the names specified in `RequestNames`.
Note that it isn't expected that existing clients connecting in the traditional way can necessarily be ported over to this new API without further notification. As pointed out by smcv in the above bug, care must be taken with the fact that names are claimed before the client has been initialized. In the common case this shouldn't make a difference, and in the case a client needs to make calls on the bus before processing incomming method calls on its names, it would either have to buffer messages, or use a separate connection to the bus for the initialization before starting to process the main connection (much could be said on that topic, I'm just mentioning it briefly here to note that it is on the radar).
If we agree that we want something like this and on a basic design, I'm happy to write it up as a patch to the spec.https://gitlab.freedesktop.org/dbus/dbus/-/issues/218Run tests under valgrind2018-11-16T15:16:49ZBugzilla Migration UserRun tests under valgrind## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#107194)](https://bugs.freedesktop.org/show_bug.cgi?id=107194)**
## Description
On Bug #105656, Philip suggested running the tests under valgri...## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#107194)](https://bugs.freedesktop.org/show_bug.cgi?id=107194)**
## Description
On Bug #105656, Philip suggested running the tests under valgrind. This is a larger task than one might think, because many of the tests are not fully valgrind-clean (and because valgrind doesn't currently work on Debian unstable due to binutils behaviour changes, so I'm having to test all this in a Debian 9 chroot).
I've mostly found false positives, but a couple of actual bugs.
Version: git masterhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/217Set default system bus socket address on ./configure to /run/dbus/system_bus_...2018-10-15T13:18:28ZBugzilla Migration UserSet default system bus socket address on ./configure to /run/dbus/system_bus_socket## Submitted by Dilian
Assigned to **D-Bus Maintainers**
**[Link to original bug (#107192)](https://bugs.freedesktop.org/show_bug.cgi?id=107192)**
## Description
Doing systemd-239/meson && ninja install uses as bus socket address ...## Submitted by Dilian
Assigned to **D-Bus Maintainers**
**[Link to original bug (#107192)](https://bugs.freedesktop.org/show_bug.cgi?id=107192)**
## Description
Doing systemd-239/meson && ninja install uses as bus socket address /run/dbus/system_bus_socket .
Doing dbus-1.12.8/configure prints:
System bus socket: /usr/local/var/run/dbus/system_bus_socket
System bus address: unix:path=/usr/local/var/run/dbus/system_bus_socket
Please adjust the defaults to match the systemd defaults on this parameter, see https://github.com/systemd/systemd/issues/9547 for discussion on systemd's side.
Note, there it is suggested to make the system bus address unconfigurable.
If you don't agree on any of this write in the documentation explictly that systemd and dbus have to be tweaked explicitly on the session bus address in order to work together.
Version: 1.12https://gitlab.freedesktop.org/dbus/dbus/-/issues/216building tests fails on Windows (msys2)2019-04-18T15:38:43ZBugzilla Migration Userbuilding tests fails on Windows (msys2)## Submitted by Vincent Torri
Assigned to **D-Bus Maintainers**
**[Link to original bug (#107051)](https://bugs.freedesktop.org/show_bug.cgi?id=107051)**
## Description
when i compile d-bus on Windows (MSYS2 + mingw-w64), using th...## Submitted by Vincent Torri
Assigned to **D-Bus Maintainers**
**[Link to original bug (#107051)](https://bugs.freedesktop.org/show_bug.cgi?id=107051)**
## Description
when i compile d-bus on Windows (MSYS2 + mingw-w64), using the autotools, i get that error:
/usr/bin/mkdir -p -m 700 XDG_RUNTIME_DIR
/usr/bin/mkdir: impossible de modifier les droits de « XDG_RUNTIME_DIR »: Permission denied
(translation : impossible to modify access rights)
trying this command directly in MSYS2 gives the same error. So passing -m 700 seems wrong when using MSYS2
Vincent Torri
Version: 1.12