dbus issueshttps://gitlab.freedesktop.org/dbus/dbus/-/issues2022-03-24T22:20:18Zhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/322Do not waste maintainer time and CI time on rebasing MRs that are otherwise OK.2022-03-24T22:20:18ZRalf HabackerDo not waste maintainer time and CI time on rebasing MRs that are otherwise OK.from https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/193#note_702966
> I think we should seriously consider going back to "Merge method: Merge commit" instead of "Merge method: Merge commit with semi-linear history", so that w...from https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/193#note_702966
> I think we should seriously consider going back to "Merge method: Merge commit" instead of "Merge method: Merge commit with semi-linear history", so that we don't have to waste maintainer time and CI time on rebasing MRs that are otherwise OK.https://gitlab.freedesktop.org/dbus/dbus/-/issues/321Ubuntu 20.04 LTS : "Software Sources" Dialog Crashes2020-11-23T11:16:28ZJijo JosephUbuntu 20.04 LTS : "Software Sources" Dialog CrashesThis might or might not be due to a bug in D-Bus. But D-Bus is the one which comes last in the crash report.
OS: Ubuntu 20.04 LTS (Budgie Desktop)
Python: Python 3.8.5
Immediately after installing the driver below, Ubuntu's software s...This might or might not be due to a bug in D-Bus. But D-Bus is the one which comes last in the crash report.
OS: Ubuntu 20.04 LTS (Budgie Desktop)
Python: Python 3.8.5
Immediately after installing the driver below, Ubuntu's software sources dialog started crashing. I know the culprit is the installation. I've uninstalled the driver but still the problem persists. What I understood from the log is that it has something to do with python. I have no knowledge of python and getting no proper answer for this issue on the web. Complete crash report is attached. Apologies if this is not directly related to d-bus but any help would be appreciated.
[HP Printer Driver](https://developers.hp.com/hp-linux-imaging-and-printing/gethplip)
[_usr_bin_software-properties-gtk.1000.crash](/uploads/10109487779df8c828030e1368664f04/_usr_bin_software-properties-gtk.1000.crash)https://gitlab.freedesktop.org/dbus/dbus/-/issues/320test-dbus-damon sporadically fails on CI building x86_64 variant2021-12-07T13:07:30ZRalf Habackertest-dbus-damon sporadically fails on CI building x86_64 variantAt !192 the following issue has been detected
```
test 14
Start 14: test-dbus-daemon
14: Test command: /usr/bin/wine "z:/builds/rhabacker/dbus/ci-build-debug-x86_64-w64-mingw32/bin/test-dbus-daemon.exe" "--tap"
14: Environment vari...At !192 the following issue has been detected
```
test 14
Start 14: test-dbus-daemon
14: Test command: /usr/bin/wine "z:/builds/rhabacker/dbus/ci-build-debug-x86_64-w64-mingw32/bin/test-dbus-daemon.exe" "--tap"
14: Environment variables:
14: DBUS_SESSION_BUS_ADDRESS=
14: DBUS_FATAL_WARNINGS=1
14: DBUS_TEST_DAEMON=z:/builds/rhabacker/dbus/ci-build-debug-x86_64-w64-mingw32/bin/dbus-daemon.exe
14: DBUS_TEST_DATA=z:/builds/rhabacker/dbus/ci-build-debug-x86_64-w64-mingw32/test/data
14: DBUS_TEST_DBUS_LAUNCH=z:/builds/rhabacker/dbus/ci-build-debug-x86_64-w64-mingw32/bin/dbus-launch.exe
14: DBUS_TEST_EXEC=z:/builds/rhabacker/dbus/ci-build-debug-x86_64-w64-mingw32/bin
14: DBUS_TEST_HOMEDIR=z:/builds/rhabacker/dbus/ci-build-debug-x86_64-w64-mingw32/dbus
14: DBUS_TEST_UNINSTALLED=1
14: Test timeout computed to be: 180
14: it looks like wine32 is missing, you should install it.
14: multiarch needs to be enabled first. as root, please
14: execute "dpkg --add-architecture i386 && apt-get update &&
14: apt-get install wine32"
14: # random seed: R02Sbd711b07332d5c7b8dbd75571371dd26
14: 1..27
14: # Resetting test timeout (reference: 0000000000600f70; factor: 1)
14: # ProcessID of this process is 8
14: # WindowsSID of this process is S-1-5-21-0-0-0-1000
14: # Time since timeout reset 0000000000600f70: 0.256 seconds
14: ok 1 /creds
14: # Resetting test timeout (reference: 0000000000601da0; factor: 1)
14: # GetConnectionUnixProcessID returned 8
14: # Time since timeout reset 0000000000601da0: 0.267 seconds
14: ok 2 /processid
14: # Start of echo tests
14: # Resetting test timeout (reference: 0000000000604560; factor: 1)
14: # max perf: 2000 messages / 8.504816 seconds
14: # Time since timeout reset 0000000000604560: 8.765 seconds
14: ok 3 /echo/session
14: # Resetting test timeout (reference: 0000000000728680; factor: 1)
14: # Bug Reference: https://bugs.freedesktop.org/show_bug.cgi?id=34393
14: # max perf: 10000 messages / 61.915981 seconds
14: # Time since timeout reset 0000000000728680: 62.281 seconds
14: Bail out! Test timed out (GLib main loop timeout callback reached)
14/34 Test #14: test-dbus-daemon .................***Failed 71.88 sec
```https://gitlab.freedesktop.org/dbus/dbus/-/issues/319CMake warning about using the package name 'GLIB22021-11-18T11:02:33ZRalf HabackerCMake warning about using the package name 'GLIB2```
CMake Warning (dev) at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:272 (message):
The package name passed to `find_package_handle_standard_args` (GLIB2) does
not match the name of the calling package (GLib2). Th...```
CMake Warning (dev) at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:272 (message):
The package name passed to `find_package_handle_standard_args` (GLIB2) does
not match the name of the calling package (GLib2). This can lead to
problems in calling code that expects `find_package` result variables
(e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
cmake/modules/FindGLib2.cmake:63 (find_package_handle_standard_args)
CMakeLists.txt:194 (find_package)
```https://gitlab.freedesktop.org/dbus/dbus/-/issues/318Required packages for cross compiling dbus on CI are outdated2022-02-25T13:05:12ZRalf HabackerRequired packages for cross compiling dbus on CI are outdatedUnder https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/184 it turned out that several mingw32-referred packages, which are fetched by the CI system, are no longer available.Under https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/184 it turned out that several mingw32-referred packages, which are fetched by the CI system, are no longer available.https://gitlab.freedesktop.org/dbus/dbus/-/issues/317Inserting Audio-CD gives "The name :1.1079 was not provided by any .service f...2021-12-06T23:45:12ZtobiasvogelInserting Audio-CD gives "The name :1.1079 was not provided by any .service files"-errorI noticed that inserting certain (not all?!) Audio CDs (not burned ones, real pressed CDs) throw the error
`The name :1.1079 was not provided by any .service files`
and while some applications like VLC are still able to play the CD, th...I noticed that inserting certain (not all?!) Audio CDs (not burned ones, real pressed CDs) throw the error
`The name :1.1079 was not provided by any .service files`
and while some applications like VLC are still able to play the CD, the application I was intending to use the CD with "SoundJuicer" cannot access the CD.
At first I believed this to be an issue with SoundJuicer, but since Nautilus also reports this error, I hope I am filing this issue correctly with DBus?
This is the output I found using dbus-monitor:
`method call time=1604582541.388282 sender=:1.1075 -> destination=org.freedesktop.DBus serial=785 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
string "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',path='/org/freedesktop/DBus',arg0=':1.1079'"
method return time=1604582541.388352 sender=org.freedesktop.DBus -> destination=:1.1075 serial=466 reply_serial=785
method call time=1604582541.389511 sender=:1.1075 -> destination=:1.1079 serial=786 path=/org/gtk/vfs/Daemon; interface=org.gtk.vfs.Daemon; member=GetConnection
error time=1604582541.389561 sender=org.freedesktop.DBus -> destination=:1.1075 error_name=org.freedesktop.DBus.Error.ServiceUnknown reply_serial=786
string "The name :1.1079 was not provided by any .service files"
method call time=1604582541.390692 sender=:1.1075 -> destination=org.freedesktop.DBus serial=787 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RemoveMatch`
I am using Ubuntu Linux Focal Fossa 20.04 with a 5.4.0-51-generic #56-Ubuntu SMP x86_64 Kernel.
The DBus-Daemon has version 1.12.16.https://gitlab.freedesktop.org/dbus/dbus/-/issues/316Incompatibility with upcoming autoconf-2.70: configure.ac:111: error: AC_REQU...2020-11-05T18:58:09ZSergei TrofimovichIncompatibility with upcoming autoconf-2.70: configure.ac:111: error: AC_REQUIRE(_AC_INIT_AUX_DIR): cannot be used outside of an AC_DEFUN'd macrAutoconf-2.70 beta3 fails to generate configure with the following error:
```
$ ./autogen.sh
Activating pre-commit hook.
I am going to run ./configure with no arguments - if you wish
to pass any to it, please specify them on the ./autog...Autoconf-2.70 beta3 fails to generate configure with the following error:
```
$ ./autogen.sh
Activating pre-commit hook.
I am going to run ./configure with no arguments - if you wish
to pass any to it, please specify them on the ./autogen.sh command line.
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build-aux'.
libtoolize: copying file 'build-aux/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
configure.ac:111: error: AC_REQUIRE(_AC_INIT_AUX_DIR): cannot be used outside of an AC_DEFUN'd macro
configure.ac:111: the top level
autom4te-2.70_beta3: error: /usr/bin/m4 failed with exit status: 1
aclocal-1.16: error: echo failed with exit status: 1
configure.ac:111: error: AC_REQUIRE(_AC_INIT_AUX_DIR): cannot be used outside of an AC_DEFUN'd macro
configure.ac:111: the top level
autom4te-2.70_beta3: error: /usr/bin/m4 failed with exit status: 1
autoheader-2.70_beta3: error: '/usr/bin/autom4te-2.70_beta3' failed with exit status: 1
configure.ac:111: error: AC_REQUIRE(_AC_INIT_AUX_DIR): cannot be used outside of an AC_DEFUN'd macro
configure.ac:111: the top level
autom4te-2.70_beta3: error: /usr/bin/m4 failed with exit status: 1
automake-1.16: error: autoconf failed with exit status: 1
configure.ac:111: error: AC_REQUIRE(_AC_INIT_AUX_DIR): cannot be used outside of an AC_DEFUN'd macro
configure.ac:111: the top level
autom4te-2.70_beta3: error: /usr/bin/m4 failed with exit status: 1
autoconf failed - version 2.5x is probably required
```https://gitlab.freedesktop.org/dbus/dbus/-/issues/315Broke dbus somehow on Ubuntu 20.04.1?2020-11-04T20:50:20Zblade1989 (Imri Paloja)Broke dbus somehow on Ubuntu 20.04.1?Last night I shut off my Ubuntu 20.04 and this morning I woke up with an un-bootable system.
In `Recovery Mode`, I found out I have two errors in the logs that seem to indicate the root cause:
- `dbus failed to open /usr/share/dbus-1/...Last night I shut off my Ubuntu 20.04 and this morning I woke up with an un-bootable system.
In `Recovery Mode`, I found out I have two errors in the logs that seem to indicate the root cause:
- `dbus failed to open /usr/share/dbus-1/system.conf permission denied`
- `Cannot setup inotify for '/usr/share/dbus-1/system.d'; error 'Permission denied'`
I tried reinstalling `dbus`, removing the `/usr/share/dbus-1` folder, and reinstalling it again, but `dbus` will not start up, thus I remain on a black screen on boot time.
Any idea what to do to fix this?https://gitlab.freedesktop.org/dbus/dbus/-/issues/314Could NOT find DBus1 (missing: DBus1_ARCH_INCLUDE_DIR) with autotools2022-09-13T11:27:55ZRalf HabackerCould NOT find DBus1 (missing: DBus1_ARCH_INCLUDE_DIR) with autotoolsAfter building dbus with autotools with the files added from !184 and running something like this
```
rm -rf /home/ralf/src/dbus-autotools-build/tmp /home/ralf/src/dbus-autotools-build/test/install
/usr/bin/ctest "--build-and-test" "/hom...After building dbus with autotools with the files added from !184 and running something like this
```
rm -rf /home/ralf/src/dbus-autotools-build/tmp /home/ralf/src/dbus-autotools-build/test/install
/usr/bin/ctest "--build-and-test" "/home/ralf/src/dbus/test/install" "/home/ralf/src/dbus-autotools-build/test/install" "--build-generator" "Unix Makefiles" "--build-makeprogram" "/usr/bin/gmake" "--build-target" "install" "--build-options" "-DDBus1_ROOT=/home/ralf/src/dbus-autotools-build/tmp/usr/local/lib64/cmake/DBus1" "-DCMAKE_INSTALL_PREFIX:PATH=/home/ralf/src/dbus-autotools-build/tmp/usr/local" "-DCHECK_VERSION=1.13.18"
```
I get
```
Error: cmake execution failed
Could NOT find DBus1 (missing: DBus1_ARCH_INCLUDE_DIR)
CMake Warning at CMakeLists.txt:8 (find_package):
Found package configuration file:
/home/ralf/src/dbus-autotools-build/tmp/usr/local/lib64/cmake/DBus1/DBus1Config.cmake
but it set DBus1_FOUND to FALSE so package "DBus1" is considered to be NOT
FOUND.
Configuring done
```
This issue blocks testing https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/172https://gitlab.freedesktop.org/dbus/dbus/-/issues/313dbus or libdbus appears to close the connection when stdin from a console (/d...2020-11-02T20:35:51ZJohn Baublitzdbus or libdbus appears to close the connection when stdin from a console (/dev/tty*) is sent as an argumentI bumped into an interesting issue where sending stdin from a process with a pseudoterminal as the controlling terminal works properly, but when run from a console, the following error is encountered: https://github.com/stratis-storage/p...I bumped into an interesting issue where sending stdin from a process with a pseudoterminal as the controlling terminal works properly, but when run from a console, the following error is encountered: https://github.com/stratis-storage/project/issues/233.
The specific error of note here is `org.freedesktop.DBus.Error.Disconnected`. We have an alternate IPC mechanism that uses Unix sockets to transfer the file descriptor so I tried sending stdin from the console to the daemon process and that worked. This rules out that this is a limitation of Unix sockets. I also wondered if this had to do with the Python libraries that we use on top of python-dbus in our Python CLI. I wanted to rule that out so I wrote a D-Bus client in Rust to invoke just the problematic D-Bus method call:
```
use std::{error::Error, io::stdin, os::unix::io::AsRawFd, time::Duration};
use dbus::{arg::OwnedFd, blocking::Connection};
fn main() -> Result<(), Box<dyn Error>> {
let key_desc = std::env::args()
.nth(1)
.ok_or_else(|| "Key description is a required argument")?;
let connection = Connection::new_system()?;
let proxy = connection.with_proxy(
"org.storage.stratis2",
"/org/storage/stratis2",
Duration::from_secs(5),
);
println!("Enter key data:");
let ((changed, _), rc, rs): ((bool, bool), u16, String) = proxy.method_call(
"org.storage.stratis2.Manager.r2",
"SetKey",
(key_desc, unsafe { OwnedFd::new(stdin().as_raw_fd()) }, true),
)?;
if rc != 0 {
Err(format!("Failed with error code {}: {}", rc, rs))?
} else if !changed {
Err("The requested action had no effect")?
} else {
Ok(())
}
}
```
This also worked from a pseudoterminal-controlled shell, and failed with the same error when run from the console. This leads me to believe that this is a bug in either dbus itself or libdbus as both the Rust library (dbus-rs) and python-dbus bind to libdbus.
One additional piece of information that might be useful is that I monitored the D-Bus while this was occuring and no call to our `SetKey` method is ever registered in `dbus-monitor` indicating that it is never actually sent across the D-Bus before the connection is closed. strace also seems to indicate that the `sendmsg` call that is supposed to send the `SetKey` message succeeds according to the return value, but immediately after that, the `recvmsg` call appears to get a `SIGHUP` and returns 0 bytes read. The file descriptor for the D-Bus connection is then closed.
Let me know if you need any more information.https://gitlab.freedesktop.org/dbus/dbus/-/issues/312how to hide a method call2021-12-07T00:01:30Zletmestudyhow to hide a method callI want to know how to hide a method call, which means that the method can be called, but the process cannot be monitored through a monitoring tool such as `dbus-monitor`. Is there a way to achieve this?I want to know how to hide a method call, which means that the method can be called, but the process cannot be monitored through a monitoring tool such as `dbus-monitor`. Is there a way to achieve this?https://gitlab.freedesktop.org/dbus/dbus/-/issues/311Inability to use X11 autolaunch on macOS2021-12-17T13:01:23ZsourtinInability to use X11 autolaunch on macOSmacOS included X11 up until version 10.7. Since its removal, X11 support is optionally provided by the [XQuartz][XQuartz] project. Unfortunately, the hostname advertised by XQuartz in the `DISPLAY` environmental variable is a path of the...macOS included X11 up until version 10.7. Since its removal, X11 support is optionally provided by the [XQuartz][XQuartz] project. Unfortunately, the hostname advertised by XQuartz in the `DISPLAY` environmental variable is a path of the form `/private/tmp/com.apple.launchd.mBSMLJ3yQU/org.macosforge.xquartz`. The consequence is that when DBus attempt to open a session file at `~/${DBUS_DIR}/${DBUS_SESSION_BUS_DIR}/${DISPLAY}` it fails because the path `~/${DBUS_DIR}/${DBUS_SESSION_BUS_DIR}//private/tmp/com.apple.launchd.mBSMLJ3yQU/` does not exist.
A simple fix is possible by replacing `/` with `_`. As `get_session_file` already replaces the (often) invalid file character `:` with `_`, this approach has precedent. This shouldn't change behaviour on any other systems as either `$DISPLAY` does not include the `/` character, in which case there is no change, or it does include it in which case DBus fails to launch on that system too.
[XQuartz]: https://www.xquartz.org/https://gitlab.freedesktop.org/dbus/dbus/-/issues/310dbus-daemon-launch-helper not installed when building with CMake2020-09-23T14:18:49ZRalf Habackerdbus-daemon-launch-helper not installed when building with CMakeWith the cmake build system the command line tool `dbus-daemon-launch-helper` is build, but not installed, which should be fixed.With the cmake build system the command line tool `dbus-daemon-launch-helper` is build, but not installed, which should be fixed.https://gitlab.freedesktop.org/dbus/dbus/-/issues/309Failure to raise FD limit on macOS (10.15.6)2021-12-17T13:01:23ZsourtinFailure to raise FD limit on macOS (10.15.6)I'm not sure from what version of macOS dbus begins to fail, but at least on 10.15.6 the following error occurs:
```
dbus-daemon[90437]: [session uid=501 pid=90437] org.freedesktop.DBus.Error.Failed: Failed to set fd limit to 9223372036...I'm not sure from what version of macOS dbus begins to fail, but at least on 10.15.6 the following error occurs:
```
dbus-daemon[90437]: [session uid=501 pid=90437] org.freedesktop.DBus.Error.Failed: Failed to set fd limit to 9223372036854775807: Invalid argument
```
This is because of the following compatibility issue as listed on `man setrlimit`:
```
COMPATIBILITY
setrlimit() now returns with errno set to EINVAL in places that historically succeeded. It no
longer accepts "rlim_cur = RLIM_INFINITY" for RLIM_NOFILE. Use "rlim_cur = min(OPEN_MAX,
rlim_max)".
```
Attached is a very simple [patch][patch] to resolve this, as indicated by the man-page suggestion.
[patch]: /uploads/0796912c292fbd19636d3ea67bbde670/macos_rlim.patchhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/308test-fdpass fails on FreeBSD: /odd-limit/at: assertion failed: dbus_message_c...2020-11-26T13:43:18ZSimon McVittietest-fdpass fails on FreeBSD: /odd-limit/at: assertion failed: dbus_message_contains_unix_fds(incoming)To reproduce: Build dbus 1.12.x on a FreeBSD 12.1 x86_64 virtual machine, with `--enable-embedded-tests`, `--enable-modular-tests`, and GLib installed. I was doing this to see whether FreeBSD is affected by the regression #304 caused by ...To reproduce: Build dbus 1.12.x on a FreeBSD 12.1 x86_64 virtual machine, with `--enable-embedded-tests`, `--enable-modular-tests`, and GLib installed. I was doing this to see whether FreeBSD is affected by the regression #304 caused by fixing #294 (that is, whether it behaves like Solaris in this respect), and if yes, whether !165 would fix it.
Expected result: The test case `test_odd_limit` in `test/fdpass.c` asserts that if we set the limit for maximum number of fds in a message to 7, and then try to send messages with 6, 7, 8 and 9 fds in, the result is that the senders of 6 or 7 fds succeed, while the senders of 8 or 9 fds get disconnected by the dbus-daemon. It should pass.
The limit is used to allocate space for out-of-band message headers (cmsg) with enough space for 7 fds.
Actual result: In at least one case (I think it's `/odd-limit/at`, which sends 7 fds), we get a D-Bus message with no fds attached to it. It might be the special `Disconnected` message that we get when disconnected, or it might be the message we expected to receive but with its fds removed - I can't immediately tell from the test's output.
I am not going to debug this myself, but *BSD users who would like dbus fd-passing to be more reliable on their platform are invited to help. (I have no idea whether other BSDs like NetBSD, OpenBSD, Dragonfly are affected; I would guess that they are somewhat likely to be, because fd-passing is quite old and the various BSDs probably share a lot of its implementation.)
fd limits that are odd numbers might be reasonably be considered pathological. Real dbus deployments probably use an even number, and are unaffected by this.https://gitlab.freedesktop.org/dbus/dbus/-/issues/306Formally deprecate forms of <policy> that we do not want to support2020-07-02T11:54:05ZSimon McVittieFormally deprecate forms of <policy> that we do not want to supportThe maintainers of dbus, and the maintainers of other D-Bus implementations like dbus-broker, have been vaguely discouraging various of the more complicated forms of `<policy>` for several years. This is intended to mitigate the fact tha...The maintainers of dbus, and the maintainers of other D-Bus implementations like dbus-broker, have been vaguely discouraging various of the more complicated forms of `<policy>` for several years. This is intended to mitigate the fact that the `<policy>` language is complicated and difficult to get right, and the fact that policy fragments intended to apply to one system service can easily have "action at a distance" on an unrelated system service.
However, this has not been particularly systematic. !76 added a section §(INTEGRATING SYSTEM SERVICES) to `dbus-daemon(1)` which encourages the approach taken by accountsservice, fwupd, udisks2 etc.; but if you search `dbus-daemon(1)` for `group`, the documentation of `<policy group=...>` does not indicate that there is anything wrong with that.
We should write down:
* Which forms of `<policy>` are encouraged (since !76 this is mostly done, by example, in §(INTEGRATING SYSTEM SERVICES))
* Which forms of `<policy>` are discouraged
* *Why* they are discouraged
* What service authors should do instead (since !76 this is mostly done, by example, in §(INTEGRATING SYSTEM SERVICES))
For the discouraged forms of `<policy>`, the documentation that says they exist should also say, in approximately the same place, that they are deprecated.
I think it has become obvious that I am not going to get this done any time soon, so if there are people who feel particularly strongly about particular features being deprecated, please step forward with merge requests.
In the long term, I would like to have a simpler policy language subset in which the deprecated/discouraged constructs are simply not expressible (see #13), but that's out-of-scope for this issue.https://gitlab.freedesktop.org/dbus/dbus/-/issues/305Dangling pointer access in dbus-userdb.c2021-03-07T11:26:50ZDaniel OnacaDangling pointer access in dbus-userdb.cHello,
I found this issue while working for a commercial product making use of D-Bus 1.10.10 release, but, by inspecting the current master, I think it is still active (please correct me if I'm wrong)
While I tend to understand the sta...Hello,
I found this issue while working for a commercial product making use of D-Bus 1.10.10 release, but, by inspecting the current master, I think it is still active (please correct me if I'm wrong)
While I tend to understand the stance of D-Bus maintainers on usage of users with different names but same UID inside /etc/passwd from [this discussion](https://github.com/systemd/systemd/issues/9503), a quick web search shows that this is, unfortunately, common practice
The issue is exposed once a set of policy rules is installed that makes use of the user attribute with values pointing to the two usernames sharing the UID. Let's consider the usernames being unameA and unameB in the order in which these will be queried by the policy parser (which always executes such queries based on user name and not based on UID). While the UID-indexed and the username-indexed hash tables will indeed have two distinct entry instances for holding the user data for unameA, their members will share the same instance in the value member. Furthermore, the key member of the entry from the username-indexed hash table will share the same (string) instance with the username member from the associated DBusUserInfo instance. When a query for unameB is executed, no entry is found and a new DBusUserInfo instance is created to hold its data. This instance gets first inserted into the UID-indexed hash table, replacing the previous one for the same UID. Upon such replace, the corresponding (now old) DBusUserInfo instance is freed, making both the value and key members from the coressponding entry in the username-indexed hash table (which will not be subsequently removed) remain as dangling pointers. This now poses the following concerns:
1. (most worrisome) The dangling key member (from the username-indexed hash-table now-"hot" entry) will be accessed:
- upon any insertion of a new DBusUserInfo instance for which the username hashes to the same bucket as the one in which the entry resides
- upon any query (in the username-indexed hash table) for an username that hashes to the same bucket but was inserted prior to unameA
- most probably upon any table rebuild of the username-indexed hash table (e.g. upon growing), with the above cases being re-employed
2. (security / functional concern) Upon a connection request from a process running under the credentials of unameA, a client policy will be created based on a provided UID (be it resolved via the socket credentials or via the AUTH EXTERNAL mechanism in which the client will usually provide the UID as it has retrieved it via geteuid). But, if the order of unameA and then unameB cache queries remained as such unchanged since last policy parsing, the group-based policy rules that will be assigned to the newly-created client policy will be based on the group IDs resolved for unameB, a set which may differ from the one unameA is part ofhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/304test-fdpass fails on Solaris derivatives after fixing CVE-2020-120492020-07-01T15:23:21ZAndy Fiddamantest-fdpass fails on Solaris derivatives after fixing CVE-2020-12049I'm working on a UNIX operating system called OmniOS, an illumos derivative (formerly OpenSolaris).
Upgrading to dbus 1.12.18 causes a new test failure in test-fdpass.
```
% gmake test-fdpass.log
PASS: test-fdpass 1 /unsupported
PASS: ...I'm working on a UNIX operating system called OmniOS, an illumos derivative (formerly OpenSolaris).
Upgrading to dbus 1.12.18 causes a new test failure in test-fdpass.
```
% gmake test-fdpass.log
PASS: test-fdpass 1 /unsupported
PASS: test-fdpass 2 /relay
PASS: test-fdpass 3 /limit
ERROR: test-fdpass - too few tests run (expected 15, got 3)
ERROR: test-fdpass - exited with status 262 (terminated by signal 6?)
```
The failure is in the `test_too_many()` function where it's waiting for the sender to be unceremoniously disconnected
```C
/* The sender is unceremoniously disconnected. */
while (dbus_connection_get_is_connected (f->left_client_conn) ||
dbus_connection_get_is_connected (f->left_server_conn))
{
test_progress ('.');
test_main_context_iterate (f->ctx, TRUE);
}
```
while in this loop, it logs:
```
dbus[29630]: invalid request, socket fd 0 not open
```
and aborts.
If I revert 872b085f12f56da25a2dbd9bd0b2dff31d5aea63 (the recent CVE fix), then the test passes again.https://gitlab.freedesktop.org/dbus/dbus/-/issues/303Follow-up from "cmake: Fix installed files"2020-06-02T06:34:24ZRalf HabackerFollow-up from "cmake: Fix installed files"The following discussion from !155 should be addressed:
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/155#note_518092):
> This is a nice idea, and I appreciate the effort to get this ...The following discussion from !155 should be addressed:
- [ ] @smcv started a [discussion](https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/155#note_518092):
> This is a nice idea, and I appreciate the effort to get this tested, but I don't think it really scales: each build takes a significant time, and adding two extra builds per feature could quickly become extremely time-consuming. If a Gitlab-CI build ends up doing multiple variant builds one after the other in a shell script loop, Gitlab can't parallelize them, so we'd end up waiting for a long time for success/failure feedback from the CMake build.
>
> Also, just checking that they compile without also running their tests doesn't seem great, and this feature seems confusingly similar to the `ci_variant` that we already have for Autotools.
>
> If we want to test additional configurations under CMake, the way to do that is to add more `ci_variant` builds to `.gitlab-ci.yml`, and include those configurations in them (they should probably be off-by-default to avoid using excessive CI resources, and we can trigger them manually when needed). For example, with Autotools, the `production` (default), `debug`, `reduced` and `legacy` variants each use different options. We don't have individual variants for each feature, because it doesn't scale - we bundle a lot of optional features being enabled into `debug`, and we bundle a lot of optional features being disabled into `reduced`.
>
> At the moment the CMake part of `tools/ci-build.sh` doesn't support variants at all. If you want to add something like
>
> ```
> (cmake|cmake-dist)
> case "$ci_variant" in
> (reduced)
> set -- "$@" -D ENABLE_SYSTEMD=OFF
> ... maybe more options here later ...
> ;;
> esac
>
> case "$ci_host" in
> (*-w64-mingw32)
> ... back to the current code ...
> ```
>
> mirroring the way it's done for Autotools, then that would be fine.
>
> The simple way to resolve this would be to drop this commit, and consider adding `ci_variant` as a separate MR.https://gitlab.freedesktop.org/dbus/dbus/-/issues/302dbus_connection_send_with_reply_and_block() never returns2020-06-03T14:39:32ZAdam Nielsendbus_connection_send_with_reply_and_block() never returnsI am debugging an issue with the LightDM display manager, which freezes during start up. The backtrace reveals that it calls `gtk_init()` which in turn calls `atspi_get_a11y_bus()` and this function calls `dbus_bus_register()`. Here, `...I am debugging an issue with the LightDM display manager, which freezes during start up. The backtrace reveals that it calls `gtk_init()` which in turn calls `atspi_get_a11y_bus()` and this function calls `dbus_bus_register()`. Here, `dbus_connection_send_with_reply_and_block()` gets called but never returns. It just sits there at `poll()` and no matter how long I leave it, nothing happens.
I am not sure how to debug this issue any further. How can I see what DBus is sending and receiving, or find out why it is not getting a reply in this case?
Also, looking at the code, there appears to be no timeout when `dbus_bus_register()` makes the blocking call. Wouldn't it be better to have a timeout so that there will at least be an error message after a few seconds rather than a permanent freeze?
In this case when I run lightdm as the root user everything works fine, but when I run it via systemd it freezes as described. When I use strace to compare the two invocations I can see that when everything works, one DBus connection is used:
```
connect(7, {sa_family=AF_UNIX, sun_path="/var/run/dbus/system_bus_socket"}, 110) = 0
sendto(7, "AUTH EXTERNAL 363230\r\n", 22, MSG_NOSIGNAL, NULL, 0) = 22
recvfrom(7, "OK 7f94aa8da629128be07028bc5e93e"..., 4096, 0, NULL, NULL) = 37
```
However when launched via systemd and it freezes, I get a different DBus connection:
```
connect(6, {sa_family=AF_UNIX, sun_path="/run/user/620/bus"}, 19) = 0
sendto(6, "AUTH EXTERNAL 363230\r\n", 22, MSG_NOSIGNAL, NULL, 0) = 22
poll([{fd=6, events=POLLIN}], 1, -1
```
I am not sure what this means.
What would cause `dbus_connection_send_with_reply_and_block()` to never return?