Bug 211314

Please use the bluez packages from http://david.woodhou.se/bluez/ and tell me if
you can reproduce this.

I haven't been able to, so far. What's different with those packages? I see
bt-applet, which mainly just lets me toggle discoverability.

Just got these:

type=AVC msg=audit(1161199971.918:240): avc:  denied  { read } for  pid=7243
comm="hidd" name="hidd" dev=dm-0 ino=1497973
scontext=system_u:system_r:bluetooth_t:s0 tcontext=user_u:object_r:var_lib_t:s0
tclass=file
type=AVC msg=audit(1161199971.918:241): avc:  denied  { lock } for  pid=7243
comm="hidd" name="hidd" dev=dm-0 ino=1497973
scontext=system_u:system_r:bluetooth_t:s0 tcontext=user_u:object_r:var_lib_t:s0
tclass=file
type=AVC msg=audit(1161199971.918:242): avc:  denied  { getattr } for  pid=7243
comm="hidd" name="hidd" dev=dm-0 ino=1497973
scontext=system_u:system_r:bluetooth_t:s0 tcontext=user_u:object_r:var_lib_t:s0
tclass=file

What policy are you using? I'm using the above-referenced bluez-utils-3.7-2
package in a clean install of FC6 and a bluetooth mouse works fine.

I'm not sure what you mean by "what policy".

Which SElinux policy.
grep SELINUXTYPE /etc/selinux/config

SELINUXTYPE=targeted

Just realized I was in Permissive mode.

Oct 18 16:10:48 tak setroubleshoot:      SELinux is preventing /usr/bin/hidd
(bluetooth_t) "read" access to hidd (var_lib_t).      See audit.log for complete
SELinux messages. id = <xxx>
Oct 18 16:10:50 tak last message repeated 9 times
Oct 18 16:10:55 tak hidd[7243]: HID create error 13 (Permission denied)
Oct 18 16:10:58 tak setroubleshoot:      SELinux is preventing /usr/bin/hidd
(bluetooth_t) "read" access to hidd (var_lib_t).      See audit.log for complete
SELinux messages. id = <xxx>

Mouse doesn't work if set to Enforcing.

ls -lR --lcontext /var/lib/bluetooth

/var/lib/bluetooth:
total 8
drwxr-xr-x 2 system_u:object_r:var_lib_t      root root 4096 Oct 18 13:44
00:0E:9B:D9:57:99

/var/lib/bluetooth/<xxx>:
total 64
-rw-r--r-- 1 user_u:object_r:bluetooth_var_lib_t root root  54 Oct 18 16:38 classes
-rw-r--r-- 1 user_u:object_r:bluetooth_var_lib_t root root  17 Oct 18 13:46 config
-rw-r--r-- 1 system_u:object_r:bluetooth_var_lib_t root root  70 Oct 18 16:38
features
-rw-r--r-- 1 user_u:object_r:var_lib_t        root root 243 Oct 18 13:46 hidd
-rw-r--r-- 1 user_u:object_r:bluetooth_var_lib_t root root  42 Oct 18 13:43 lastseen
-rw-r--r-- 1 user_u:object_r:bluetooth_var_lib_t root root  42 Oct 18 16:38 lastused
-rw-r--r-- 1 user_u:object_r:bluetooth_var_lib_t root root  28 Oct 18 13:44
manufacturers
-rw-r--r-- 1 system_u:object_r:bluetooth_var_lib_t root root 222 Oct 18 16:38 names

Ok, so /var/lib/bluetooth/00:0E:9B:D9:57:99/hidd managed to get created with the
wrong context. Remove it and re-pair with the device (or briefly run hidd with
the  -Z option while letting it reconnect. It _should_ get created with the
correct context.

I think I have to defer to selinux folks now; I'm getting out of my depth
because I don't quite understand where the labels are derived from when files
are created.

The problem is the /var/lib/bluetooth directory was created with wrong context.
It should be bluetooth_var_lib_t.  Did this directory get created after the rpm
install?  RPM should have set the correct context on the directory.

restorecon -R -v /var/lib/bluetooth

should fix.

I don't know when /var/lib/bluetooth was created. Possibly in an older version
of the package. If restorecon can fix this problem, why isn't it being run in a
%post or something? This isn't something the user should have to do.

This is not somethine we are seeing, if the user deletes and recreates the
directory and it has the wrong permissions on it, there is nothing we can do
other than tell them how to correct the permissions, which is basically what
this error is.  If you delete the directory and recreate it then this could
happen, also if they ran deleted the directory and ran the hidd by hand it could
happen if hidd creates the directory.  I am updating policy to allow this to be
created with the correct context.

Just so we're clear, I didn't delete the directory, or otherwise change it.

The bluez-utils package owns this directory -- it should have been created when
the package was installed, and I believe it's supposed to magically get the
right label somehow, whether that's during the install or by manually installing
it with yum or rpm later.

Was this a clean install of rawhide? An upgrade? Had selinux ever been disabled?
Was bluez-utils installed from the beginning or was it updated later?

There also could have been a policy update where the label was changed, and for
some reason this directory did not get labeled correctly.  So I think we can
cloase this bug for now and reopen it if it reappears.

This was originally an FC5 install that I updated to rawhide a few weeks ago.
selinux was never disabled, but it did spend a lot of time in permissive mode.
bluez-utils was installed at the very beginning, with FC5.

I'm not really comfortable with closing this bug, as it makes hardware that
should work... not work. There should be a way to ensure that labels are
correct, no?

Yes you can relabel the entire system.

# touch /.autorelabel
# reboot

You can also check the labeles on the system 

# fixfiles check

rpm -V should show you a problem,  but bugs on updates to happen, and something
happened on a rawhide update to set this label incorrectly or not correct the
label (more likely). 

This is similar to if the Ownership or mode on the file was wrong.  There is
limited ways to 

It looks like the end of your comment was cut off.

I've seen the /.autorelabel workaround suggested before, for different issues.
Why don't we ship with /.autorelabel? I'm looking for a solution that doesn't
require a customer to make support calls, and eventually escalate to IT.

I ran 'fixfiles check', and here was the relevant output:
/sbin/restorecon reset /var/lib/bluetooth/00:0E:9B:D9:57:99 context
system_u:object_r:var_lib_t:s0->system_u:object_r:bluetooth_var_lib_t:s0
/sbin/restorecon reset /var/lib/bluetooth/00:0E:9B:D9:57:99/hidd context
user_u:object_r:var_lib_t:s0->system_u:object_r:bluetooth_var_lib_t:s0

Notice how /var/lib/bluetooth/ isn't mentioned; just the subdirectory.

# rpm -V bluez-utils; echo $?
0

On an upgrade install I believe /.autorelabel is going to be turned on for
RHEL5.  But for this update it was not.

The update scripts attempt to fix the context, but sometimes they miss.

restorecon -R -v /var/lib/bluetooth would have fixed the problem also without
the full autorelabel