Hide Forgot
SELinux is preventing bluetoothd from 'unlink' accesses on the sock_file sdp. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that bluetoothd should be allowed unlink access on the sdp sock_file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep bluetoothd /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:bluetooth_t:s0 Target Context unconfined_u:object_r:var_run_t:s0 Target Objects sdp [ sock_file ] Source bluetoothd Source Path bluetoothd Port <Unbekannt> Host (removed) Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.9.16-26.fc15 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 2.6.38.6-27.fc15.x86_64 #1 SMP Sun May 15 17:23:28 UTC 2011 x86_64 x86_64 Alert Count 1 First Seen Sa 04 Jun 2011 12:40:57 CEST Last Seen Sa 04 Jun 2011 12:40:57 CEST Local ID 69514553-52ed-485c-a5be-214ce7ccb4c7 Raw Audit Messages type=AVC msg=audit(1307184057.525:74): avc: denied { unlink } for pid=2303 comm="bluetoothd" name="sdp" dev=tmpfs ino=26845 scontext=system_u:system_r:bluetooth_t:s0 tcontext=unconfined_u:object_r:var_run_t:s0 tclass=sock_file Hash: bluetoothd,bluetooth_t,var_run_t,sock_file,unlink audit2allow #============= bluetooth_t ============== allow bluetooth_t var_run_t:sock_file unlink; audit2allow -R #============= bluetooth_t ============== allow bluetooth_t var_run_t:sock_file unlink;
Any idea what created that "sdp" sock file in /var/run.* ? I suspect that whatever created it may need policy.
My bluetooth daemon's behaviour has been rather unpredictable lately. I didn't use bluetooth for quite a while (about 4 weeks) and today I needed it to connect to my mobile phone. It simply didn't work: Jun 4 12:28:05 fedora dbus: [system] Activating via systemd: service name='org.bluez' unit='dbus-org.bluez.service' Jun 4 12:28:05 fedora dbus: [system] Activation via systemd failed for unit 'dbus-org.bluez.service': Unit dbus-org.bluez.service failed to load: No such file or directory. See system logs and 'systemctl status' for details. I had tons of these in my /var/log/messages. Further more this: Jun 4 12:18:48 fedora bluetoothd[2481]: Unable to get on D-Bus I was desperately trying to bring back bluetooth functionality, when suddenly the above selinux-error appeared. I have no idea what caused this, but it was one clue, where all those problems come from. So I filed a bug report about it. What I tried was: Manually disabling and enabling bluetooth via /proc/acpi/ibm/bluetooth and via gnome-shell - both without success. Then I manually started "bluetoothd -n" from a command line and suddenly bluetooth worked! But after a reboot I would always have to start bluetoothd manually... This was not satisfying, so I tried to find out more about this daemon and got to know the command "systemctl enable bluetooth.service". This must have been the time when suddenly the selinux-error appeared and I filed this bug. After some more reboots and tests, the bluetooth problems suddenly vanished mysteriously. Until this moment, the above errors in /var/log/messages have not reappeared! The bluetooth service starts automatically and flawlessly. The selinux-error didn't appear again! So this lets me stand here quite confused, I'm afraid. I have no idea, whether this error is still relevant for a bug report at all. Maybe we close this and anybody who runs in this problem again will just reopen it...?
The problem was you started bluetoothd by hand and after that using a service script. If you start a daemon by hand then it runs in unconfined_t domain and files such as pid, log files are created with wrong labels. In this case it was the sdp socket /var/run/sdp -s gen_context(system_u:object_r:bluetooth_var_run_t,s0)
*** Bug 890044 has been marked as a duplicate of this bug. ***