Bug 191642 - Bluetooth doesn't store session data in enforcing mode.
Bluetooth doesn't store session data in enforcing mode.
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Depends On:
  Show dependency treegraph
Reported: 2006-05-14 08:32 EDT by Leszek Matok
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-05-23 16:47:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
relevant part of /var/log/messages (5.34 KB, text/plain)
2006-05-14 08:32 EDT, Leszek Matok
no flags Details

  None (edit)
Description Leszek Matok 2006-05-14 08:32:35 EDT
I'm attaching a fragment of my /var/log/messages showing the effects of a
successful connection to Bluetooth device (mobile phone). The connection was
initiated by simple "cat /dev/rfcomm0", then it asked for a PIN and
authenticated properly. So there's no big problem here, things seem to still
work, only I have to enter new PIN both on the phone and computer every time I
want to connect.

If I run setenforce 0 as root and connect once (entering the PIN), the
session/PIN/whatever is saved, so I can connect any time I want with no clicking
anywhere. I can run setenforce 1 then and still connect automatically.

This is selinux-policy-targeted-2.2.36-2.fc5
Comment 1 Leszek Matok 2006-05-14 08:32:36 EDT
Created attachment 129003 [details]
relevant part of /var/log/messages
Comment 2 Daniel Walsh 2006-05-15 13:24:35 EDT
You can 
restorecon /var/lib/bluetooth

Which should get rid of one of the AVC messages.  This directory should be
created and owned by bluez-utils.

What cache file is it trying to read from /var/?  How was this file created?

Comment 3 Leszek Matok 2006-05-15 15:42:36 EDT
You were right, /var/lib/bluetooth had system_u:object_r:var_lib_t context,
restorecon changes it. But `rpm -qf /var/lib/bluetooth` says it doesn't belong
to any package, `rpm -ql bluez-utils|grep var` doesn't find anything there.

I checked on a friend's FC5, he has bluez-utils installed, but doesn't use
Bluetooth and there's no /var/lib/bluetooth at all (so it's not created by
post-installs script or something).

Now, for me (after restorecon), it creates directory
/var/lib/bluetooth/11:11:11:11:11:11 (which is the MAC of my device, strange but
true), where it stores /var/lib/bluetooth/11:11:11:11:11:11/linkkeys and
everything works just right.

So the problem is rather with creation of /var/lib/bluetooth and not
selinux-policy (sorry). In my case, if I `rm -rf /var/lib/bluetooth` as root and
run `hcitool scan` as normal user (with enforcing disabled temporarily, as I
said in my previous message), /var/lib/bluetooth instantly appears as:
drwxr-xr-x 3 user_u:object_r:var_lib_t        root root 4096 maj 15 21:20
I think that because the file is absent, hcid creates it with this context and
this is shown in dmesg.

Will we get bluez-utils update then?
Comment 4 Daniel Walsh 2006-05-23 16:47:04 EDT
Fixed in rawhide. Hopefully will get updated soon in FC5

Note You need to log in before you can comment on or make changes to this bug.