/usr/libexec/dbus-daemon-launch-helper is installed as root:root. This prevents a bunch of D-Bus services from being started due to permissions, for example in KDE/Plasma. One example that makes this immediately visible is starting powerdevil, which leads to the following warnings in the log: Jun 28 03:45:55 kaon dbus-daemon[1198]: [system] Activating service name='org.kde.powerdevil.discretegpuhelper' requested by ':1.26' (uid=1000 pid=1886 comm="/usr/lib64/libexec/org_kde_powerdevil ") (using servicehelper) Jun 28 03:45:55 kaon dbus-daemon[1198]: [system] Activated service 'org.kde.powerdevil.discretegpuhelper' failed: Failed to execute program org.kde.powerdevil.discretegpuhelper: Permission denied Jun 28 03:45:55 kaon org_kde_powerdevil[1886]: org.kde.powerdevil: org.kde.powerdevil.discretegpuhelper.hasdualgpu failed Jun 28 03:45:55 kaon dbus-daemon[1198]: [system] Activating service name='org.kde.powerdevil.chargethresholdhelper' requested by ':1.26' (uid=1000 pid=1886 comm="/usr/lib64/libexec/org_kde_powerdevil ") (using servicehelper) Jun 28 03:45:55 kaon dbus-daemon[1198]: [system] Activated service 'org.kde.powerdevil.chargethresholdhelper' failed: Failed to execute program org.kde.powerdevil.chargethresholdhelper: Permission denied Jun 28 03:45:55 kaon org_kde_powerdevil[1886]: org.kde.powerdevil: org.kde.powerdevil.chargethresholdhelper.getthreshold failed "DBus Backend error: service start org.kde.powerdevil.chargethresholdhelper failed: Failed to execute program org.kde.powe> Jun 28 03:45:55 kaon dbus-daemon[1198]: [system] Activating service name='org.kde.powerdevil.backlighthelper' requested by ':1.26' (uid=1000 pid=1886 comm="/usr/lib64/libexec/org_kde_powerdevil ") (using servicehelper) Jun 28 03:45:55 kaon dbus-daemon[1198]: [system] Activated service 'org.kde.powerdevil.backlighthelper' failed: Failed to execute program org.kde.powerdevil.backlighthelper: Permission denied Jun 28 03:45:55 kaon org_kde_powerdevil[1886]: org.kde.powerdevil: org.kde.powerdevil.backlighthelper.brightness failed Another services that fail for the same reason include org.kde.kded.smart and org.kde.kcontrol.kcmsddm. After fixing the group and permissions of the launch helper, things work as expected: # chgrp messagebus /usr/libexec/dbus-daemon-launch-helper # chmod 4750 /usr/libexec/dbus-daemon-launch-helper I can see exactly this snippet in the Makefile, too, but I have no clue why it's not executed. Reproducible: Always Steps to Reproduce: 1. emerge dbus 2. ls -lh /usr/libexec/dbus-daemon-launch-helper -rws--x--- 1 root root 56K 28. Jun 17:54 /usr/libexec/dbus-daemon-launch-helper Actual Results: Launch helper installed as root:root, preventing the start of suid services due to permission problems. Expected Results: Launch helper installed as root:messagebus, allowing the start of suid services for unprivileged users.
Created attachment 719850 [details] emerge --info
FYI, for me it is: ls -l /usr/libexec/dbus-daemon-launch-helper -rws--x--- 1 root messagebus 60656 Dec 28 13:00 /usr/libexec/dbus-daemon-launch-helper*
On my system, the file has the correct permissions. Please attach a build log.
Created attachment 720093 [details] build.log
Created attachment 720096 [details] build-abi_x86_64.amd64.log
Logs attached. I couldn't see anything suspicious in them... in fact, the chown command seems to be executed. I have absolutely no clue what's going on. In the build dir, the file belongs to portage:portage. FWIW, my system is built with clang/libc++, but I'm not sure that this matters? I've tried rebuilding just dbus with GCC/libstdc++, that did not help with the permission problem. I can reproduce this on three computers (all built with clang though). It used to work fine until a few weeks or couple of months ago, which is when I noticed that brightness could not longer be changed on my (rarely used) laptop, but I can't pinpoint a particular time frame.
Going through my backups, I can see that it broke somewhere between mid-April and mid-May, which is about the time when I switched my systems to Clang. However, that switch meant I was rebuilding world including dbus, which had not been rebuilt before since January, so I cannot be sure that the move to Clang is the culprit here, or if it just made an earlier issue visible due to the rebuild. One thing that also changed around the same time was the introduction of lots of acct-user ebuilds.
Okay, so the culprit seems to be using llvm-objcopy instead of GCC's objcopy. When changing back to the latter, user/group are correct again. I can reproduce on all of the affected systems by setting OBJCOPY accordingly. However, GCC's objcopy produces a ton of warnings on a system built with Clang/libc++, that's why I switched to the LLVM version... Now I don't know enough about toolchains to see how the flavor of objcopy tool would affect the group of a file like this, but I'm attaching two build logs (one wich llvm-objcopy resulting in broken dbus-daemon-launch-helper, one with GCC's objcopy that produces the expected result) that might help you hopefully...
Portage probably calls objcopy when stripping binaries. Try setting FEATURES="nostrip" as a test.
Created attachment 721098 [details] Build with GCC's objcopy With GCC's objcopy, the file belongs to the expected group: dyon ~ # ll /usr/libexec/dbus-daemon-launch-helper -rws--x--- 1 root messagebus 56104 2. Jul 20:12 /usr/libexec/dbus-daemon-launch-helper
Created attachment 721101 [details] Build with llvm-objcopy With llvm-objcopy, group gets lost: dyon ~ # ll /usr/libexec/dbus-daemon-launch-helper -rws--x--- 1 root root 56208 2. Jul 18:52 /usr/libexec/dbus-daemon-launch-helper
And just to add one more data point, I can reproduce the same issue by using llvm-strip instead of the default version, while keeping all the other utils (including objcopy) at their GCC default...
(In reply to Mike Gilbert from comment #9) > Portage probably calls objcopy when stripping binaries. Try setting > FEATURES="nostrip" as a test. This also avoids the issue, so it seems indeed to be related to that. Question is, is this a bug in the LLVM tooling, does the dbus build do something special, and am I breaking more things in my system that I haven't noticed yet by using the LLVM utils globally?
Well, it's really just a difference in behavior between binutils and llvm. It's hard to say which is "correct", but the binutils behavior is probably much older and well established.
I'm pretty sure I've seen this problem reported somewhere but I don't really recall what was the conclusion. I see [1] so maybe it's fixed in a newer version? [1] https://reviews.llvm.org/D93881
https://github.com/llvm/llvm-project/commit/c2a84771bb63947695ea50b89160c02b36fb634d https://github.com/llvm/llvm-project/commit/17b4e695ce0ef89eac4a37df2df49d4c0e700766 https://github.com/llvm/llvm-project/commit/4f16e177e104eb80589311dc3cc1b5355a7e41bb https://github.com/llvm/llvm-project/commit/021de7cf80268091cf13485a538b611b37d0b33e https://github.com/llvm/llvm-project/commit/f134a7158b1eb1b1a63dc402b46a57bf6e5ec897 https://github.com/llvm/llvm-project/commit/972b6a3a3471c2a742c5c5d8ec004ff640d544c4 https://github.com/llvm/llvm-project/commit/ee8a5e4bc2c986b8e6c07e81fb58dc1e5a5c2d17 All these commits were made on branch "main" after branch "release/12.x" was created, so they are not included in LLVM 12.0.0. Could they be backported in Gentoo? (LLVM 13.0.0 is currently scheduled to be released on 2021-09-21.)
f134a7158b1e doesn't apply cleanly, and I have trouble rebasing it.
Let's skip f134a7158b1eb1b1a63dc402b46a57bf6e5ec897 and 972b6a3a3471c2a742c5c5d8ec004ff640d544c4.
Created attachment 725476 [details, diff] llvm ebuild patch Well, I've tried that and I can't reproduce any difference. Any clue how to test the fix properly?
Ok, I see my error, lemme try again.
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #18) > Let's skip f134a7158b1eb1b1a63dc402b46a57bf6e5ec897 and > 972b6a3a3471c2a742c5c5d8ec004ff640d544c4. The tool seems to be broken now: + /var/tmp/portage/sys-devel/llvm-12.0.1-r1/work/llvm-12.0.1_build-abi_x86_32.x86/bin/llvm-objcopy --build-id-link-dir=/var/tmp/portage/sys-devel/llvm-12.0.1-r1/work/llvm-12.0.1_build-abi_x86_32.x86/test/tools/llvm-objcopy/ELF/Output/build-id-link-dir.test.tmp-dir --build-id-link-output '' --strip-sections /var/tmp/portage/sys-devel/llvm-12.0.1-r1/work/llvm-12.0.1_build-abi_x86_32.x86/test/tools/llvm-objcopy/ELF/Output/build-id-link-dir.test.tmp /var/tmp/portage/sys-devel/llvm-12.0.1-r1/work/llvm-12.0.1_build-abi_x86_32.x86/test/tools/llvm-objcopy/ELF/Output/build-id-link-dir.test.tmp4 LLVM ERROR: IO failure on output stream: Bad file descriptor PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: /var/tmp/portage/sys-devel/llvm-12.0.1-r1/work/llvm-12.0.1_build-abi_x86_32.x86/bin/llvm-objcopy --build-id-link-dir=/var/tmp/portage/sys-devel/llvm-12.0.1-r1/work/llvm-12.0.1_build-abi_x86_32.x86/test/tools/llvm-objcopy/ELF/Output/build-id-link-dir.test.tmp-dir --build-id-link-output --strip-sections /var/tmp/portage/sys-devel/llvm-12.0.1-r1/work/llvm-12.0.1_build-abi_x86_32.x86/test/tools/llvm-objcopy/ELF/Output/build-id-link-dir.test.tmp /var/tmp/portage/sys-devel/llvm-12.0.1-r1/work/llvm-12.0.1_build-abi_x86_32.x86/test/tools/llvm-objcopy/ELF/Output/build-id-link-dir.test.tmp4 #0 0xfffffffff261eb17 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/var/tmp/portage/sys-devel/llvm-12.0.1-r1/work/llvm-12.0.1_build-abi_x86_32.x86/bin/../lib/libLLVM-12.so+0x991b17) #1 0xfffffffff261ec6f PrintStackTraceSignalHandler(void*) (/var/tmp/portage/sys-devel/llvm-12.0.1-r1/work/llvm-12.0.1_build-abi_x86_32.x86/bin/../lib/libLLVM-12.so+0x991c6f) #2 0xfffffffff261c821 llvm::sys::RunSignalHandlers() (/var/tmp/portage/sys-devel/llvm-12.0.1-r1/work/llvm-12.0.1_build-abi_x86_32.x86/bin/../lib/libLLVM-12.so+0x98f821) #3 0xfffffffff261c9b3 SignalHandler(int) (/var/tmp/portage/sys-devel/llvm-12.0.1-r1/work/llvm-12.0.1_build-abi_x86_32.x86/bin/../lib/libLLVM-12.so+0x98f9b3) #4 0xfffffffff7f3e560 (linux-gate.so.1+0x560) #5 0xfffffffff7f3e549 (linux-gate.so.1+0x549) #6 0xfffffffff18897ac raise /tmp/portage/sys-libs/glibc-2.33-r3/work/glibc-2.33/signal/../sysdeps/unix/sysv/linux/raise.c:50:1 #7 0xfffffffff1872305 abort /tmp/portage/sys-libs/glibc-2.33-r3/work/glibc-2.33/stdlib/abort.c:81:7 #8 0xfffffffff2557131 llvm::report_fatal_error(llvm::Twine const&, bool) (/var/tmp/portage/sys-devel/llvm-12.0.1-r1/work/llvm-12.0.1_build-abi_x86_32.x86/bin/../lib/libLLVM-12.so+0x8ca131) #9 0xfffffffff25572da (/var/tmp/portage/sys-devel/llvm-12.0.1-r1/work/llvm-12.0.1_build-abi_x86_32.x86/bin/../lib/libLLVM-12.so+0x8ca2da) #10 0xfffffffff25f8c5f llvm::raw_fd_ostream::~raw_fd_ostream() (/var/tmp/portage/sys-devel/llvm-12.0.1-r1/work/llvm-12.0.1_build-abi_x86_32.x86/bin/../lib/libLLVM-12.so+0x96bc5f) #11 0x565e3b32 llvm::objcopy::writeToFile(llvm::StringRef, std::function<llvm::Error (llvm::raw_ostream&)>) (/var/tmp/portage/sys-devel/llvm-12.0.1-r1/work/llvm-12.0.1_build-abi_x86_32.x86/bin/llvm-objcopy+0x28b32) #12 0x565cc832 main (/var/tmp/portage/sys-devel/llvm-12.0.1-r1/work/llvm-12.0.1_build-abi_x86_32.x86/bin/llvm-objcopy+0x11832) #13 0xfffffffff1873925 __libc_start_main /tmp/portage/sys-libs/glibc-2.33-r3/work/glibc-2.33/csu/../csu/libc-start.c:332:16 #14 0x565ccd81 _start (/var/tmp/portage/sys-devel/llvm-12.0.1-r1/work/llvm-12.0.1_build-abi_x86_32.x86/bin/llvm-objcopy+0x11d81) /var/tmp/portage/sys-devel/llvm-12.0.1-r1/work/llvm-12.0.1_build-abi_x86_32.x86/test/tools/llvm-objcopy/ELF/Output/build-id-link-dir.test.script: line 26: 182311 Aborted (core dumped) /var/tmp/portage/sys-devel/llvm-12.0.1-r1/work/llvm-12.0.1_build-abi_x86_32.x86/bin/llvm-objcopy --build-id-link-dir=/var/tmp/portage/sys-devel/llvm-12.0.1-r1/work/llvm-12.0.1_build-abi_x86_32.x86/test/tools/llvm-objcopy/ELF/Output/build-id-link-dir.test.tmp-dir --build-id-link-output "" --strip-sections /var/tmp/portage/sys-devel/llvm-12.0.1-r1/work/llvm-12.0.1_build-abi_x86_32.x86/test/tools/llvm-objcopy/ELF/Output/build-id-link-dir.test.tmp /var/tmp/portage/sys-devel/llvm-12.0.1-r1/work/llvm-12.0.1_build-abi_x86_32.x86/test/tools/llvm-objcopy/ELF/Output/build-id-link-dir.test.tmp4
