Emerging the package net-wireless/bluez create the directory /etc/bluetooth with permission 0755. The service file /usr/lib/systemd/system/bluetooth.service contains the directive ConfigurationDirectoryMode=0555. As the directory has already been create with a different permission mask, systemd does not alter it when the service is started, but logs the message bluetooth.service: ConfigurationDirectory 'bluetooth' already exists but the mode is different. (File system: 755 ConfigurationDirectoryMode: 555) at the severity level "warning". Either the service file should be fixed (such that 0755 is acceptable) or the ebuild script should be fixed to set permissions to 0555. Reproducible: Always Steps to Reproduce: 1. Emerge net-wireless/bluez 2. Start service, e.g. systemctl start bluetooth.service 3. Look out for warning message in system log Actual Results: A unnecessary warning is logged. Expected Results: No warning should be logged.
I have tried to set 555 mode via fperms / insopts... but at the end it stays as 755. Is there any restriction applied by portage to apply 555 mode? (it is true that, to me, it looks a bit stupid as root can still play with the files as with 755)
Portage never adjusts the permissions on directories once they have already been created. To update the permissions for existing installations, you will need to call chmod from pkg_postinst. Really though, that mode makes no sense and should just be removed from the service file to allow the default of 0755 to be used.
(In reply to Mike Gilbert from comment #2) [...] > Really though, that mode makes no sense and should just be removed from the > service file to allow the default of 0755 to be used. I agree with you, but looking to other distributions, it seemed to me that they failed to convince upstream to stop trying to enforce 0555 :S, we will probably need to carry the change downstream forever then :/
So it turns out that the upstream build system actually creates $(DESTDIR)/etc/bluetooth with the 0755 mode. There's a hack in Makefile.am that is intended to "correct" the permissions to 0555, but that hack fails because it is calling "install -dm555" after the directory already exists. > bluetoothd-fix-permissions: > install -dm555 $(DESTDIR)$(confdir) > install -dm700 $(DESTDIR)$(statedir) It should call "chmod 555" instead. To fix this in the ebuild, you could call fperms 0555 /etc/bluetooth at the end of the install phase. That will resolve the issue for fresh installs. For existing installs, I would suggest you ignore the warning and let users adjust the mode manually if they so desire. The alternative is to call chmod in pkg_postinst, but that could possibly override any permissions set manually by the sysadmin. Some other notes: The ebuild is calling keepdir /etc/bluetooth for no apparent reason. You don't need keepdir if you are installing files under the directory. Also, the build system seems to install files into /etc/bluetooth already, so the manual installation of those same files by the ebuild seems redundant. You should probably look into that.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8f47f2d2422bca990ac5acbe736c62abc96074a9 commit 8f47f2d2422bca990ac5acbe736c62abc96074a9 Author: Pacho Ramos <pacho@gentoo.org> AuthorDate: 2024-05-18 11:07:58 +0000 Commit: Pacho Ramos <pacho@gentoo.org> CommitDate: 2024-05-18 11:08:01 +0000 net-wireless/bluez: add 5.76 Also try to enforce 555 permissions (as wanted by upstream) for new installs, for current systems, admin will need to change the manually if desired (even if the systemd warning is harmless and 555 permissions make no much sense anyway https://github.com/bluez/bluez/issues/414). Also fix redundant manual installing of several files. Thanks-to: Matthias Nagel Thanks-to: Mike Gilbert Closes: https://bugs.gentoo.org/929017 Signed-off-by: Pacho Ramos <pacho@gentoo.org> net-wireless/bluez/Manifest | 1 + net-wireless/bluez/bluez-5.76.ebuild | 273 +++++++++++++++++++++++++++++++++++ 2 files changed, 274 insertions(+)
Currently it does affect not only the new installations. The file permissions get changed after re-emerging bluez. E.g. after chmod 644 /etc/bluetooth/* emerge net-wireless/bluez ls -la /etc/bluetooth -r-xr-xr-x 1 root root 928 May 19 21:53 input.conf -rw-r--r-- 1 root root 12595 May 19 21:37 main.conf -r-xr-xr-x 1 root root 1385 May 19 21:53 mesh-main.conf -r-xr-xr-x 1 root root 120 May 19 21:53 network.conf After updating to bluez-5.76 for the first time, main.conf permissions were modified as well. Those weird permissions prevented me from using dispatch-conf to deal with the proposed update to main.conf, had to do it manually.
Interesting commit upstream: https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=7665fb5d943c3910465123fc7b08922e44adb7a2
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6ace5b9410d153c03933a39338690f98dffbfdf0 commit 6ace5b9410d153c03933a39338690f98dffbfdf0 Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2024-05-19 21:08:04 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2024-05-19 21:08:04 +0000 net-wireless/bluez: fixup permissions Set 0555 mode on /etc/bluetooth directory only. It makes no sense to apply this recursively. keepdir /var/lib/bluetooth when systemd is disabled. Set mode to 0700. See upstream: https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=7665fb5d943c3910465123fc7b08922e44adb7a2 Bug: https://bugs.gentoo.org/929017 Closes: https://bugs.gentoo.org/932172 Signed-off-by: Mike Gilbert <floppym@gentoo.org> net-wireless/bluez/{bluez-5.76.ebuild => bluez-5.76-r1.ebuild} | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
