On Wed, 2006-03-15 at 21:42 +0100, Patrick von der Hagen wrote: > William John Murray wrote: > [...] > > Hello Patrick, > > I think you have to disable the bluetooth in selinux, > > (SElinux -> SELinux service protection -> bluetooth) > Yes, you are right, that solved my problem. Strange thing is, I never > had problems starting hcid manually, just the init-script won't work > when bluetooth is disallowed by selinux. I just sat down and figured this out -- SELinux policy isn't currently allowing hcid (which runs as bluetooth_t) to connect to the system message bus. I just sent dwalsh the relevant policy patch > OK, let's see... Bug 1: "/etc/init.d/bluetooth start" reports success, > though "hcid" fails to start. Easy solution: verify that hcid started. > Better solution: verify whether selinux disallows bluethooth and have > the init-script report "failed to start due to selinux". Well, it should actually start :-) > Bug 2: why can I start "hcid" manually, though bluetooth is disallowed > by selinux? I suppose selinux should either allow both the init-script > and manual invocation or deny both the init-script and manual > invocation. The current situation is certainly annoying. When you start it manually, it runs as unconfined_t instead of transitioning to bluetooth_t and thus can connect to the bus. > > The pin ID stuff is probably related to requiring a pin helper. > > I uncommented /usr/bin/bluepin in /etc/bluetooth/hcid.conf, > > and the error went away. > That one helped here to. I thought that would not be nessessary since a > different pin-helper was configured. It should be verified with kde, but > I consider this to be bug 3. It should be calling the dbus method which bluez-pin listens for. Note that bluez-pin wasn't be automatically started in X sessions until bluez-pin-0.30-1 Jeremy -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list