Description of problem: SSIA. Version-Release number of selected component (if applicable): bluez-utils-2.25-4 How reproducible: Always Steps to Reproduce: 1. configure hcid.conf to use /usr/bin/bluepin 2. launch something that requires pairing 3. enter a pin on your phone Actual results: failure log contains: Aug 30 16:55:59 stinker hcid[3389]: pin_code_request (sba=SNIP, dba=SNIP) Aug 30 16:55:59 stinker kernel: audit(1156949759.482:5): avc: denied { search } for pid=3404 comm="bluepin" name="gdm" dev=sda1 ino=4235674 scontext=user_u:system_r:bluetooth_helper_t:s0 tcontext=system_u:object_r:xserver_log_t:s0 tclass=dir Aug 30 16:55:59 stinker hcid[3403]: PIN helper exited abnormally with code 256 The phone then said the PINs didn't match. When I disabled SELinux, everything went OK - the dialog window popped up etc. Expected results: It should work even with SELinux in Enforcing mode.
An selinux-policy bug, then? BTW the xserver_log_t directory in question is /var/gdm.
Changing ownership :)
Fixed in selinux-policy-2.3.14-4
Not sure how relevant this bug is when FC5 still has selinux-policy-2.3.7-2.fc5 and FC6 obsoletes bluez-pin in favor of bluez-gnome (which doesn't have this issue, btw). NEXTRELEASE or WONTFIX, whatever...
Closing bugs