Description of problem: Configuring a fresh Fedora 37 instance and checked the result with: $ sudo oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_standard --report report.html /usr/share/xml/scap/ssg/content/ssg-fedora-ds.xml detected permissions changes on bluez. Manual check also show it: # rpm -qV bluez .M....... /var/lib/bluetooth # rpm -qlv bluez |grep /var/lib drwxr-xr-x 2 root root 0 set 1 22:27 /var/lib/bluetooth drwxr-xr-x 2 root root 0 set 1 22:27 /var/lib/bluetooth/mesh # ls -ld /var/lib/bluetooth /var/lib/bluetooth/mesh drwx------. 1 root root 42 1 set 22.27 /var/lib/bluetooth drwxr-xr-x. 1 root root 0 1 set 22.27 /var/lib/bluetooth/mesh Applying the proposed fix `rpm --restore bluez` work for a while, then something changes again the permissions on the directory. If the required permissions are `drwx------` I think the bluez packaging should be corrected accordingly. If soomething is changing the permissions there without being supposed to, it should be identified and fixed for not doing it. Version-Release number of selected component (if applicable): # rpm -qv bluez bluez-5.65-3.fc37.x86_64
Looking at the journal I saw now: ``` systemd[1303]: ConfigurationDirectory 'bluetooth' already exists but the mode is different. (File system: 755 ConfigurationDirectoryMode: 555) ``` so ConfigurationDirectoryMode is different from both the rpm required mode and the filesystem runtime mode. Not sure if this needs to be tracked on a different bz.
Still reproducible on Fedora 38: bluez-5.66-5.fc38.x86_64
*** Bug 2116384 has been marked as a duplicate of this bug. ***