> On Mar 2, 2017, at 12:01 AM, Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote:
>
> Hi Travis,
>
> On Wed, Mar 1, 2017 at 7:27 PM, Travis Griggs <travisgriggs@xxxxxxxxx> wrote:
>>
>>> On Mar 1, 2017, at 8:35 AM, Travis Griggs <travisgriggs@xxxxxxxxx> wrote:
>>>
>>> This is not directly bluez/ble related, but rather derived from their use. I’ve been prototyping my BLE peripheral behavior running as root. Now I’m hardening things and partitioning the BLE app to a non-root user. My service now errors out with the following:
>>>
>>> dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 2 matched rule
>>> s; type="method_call", sender=":1.6797" (uid=107 pid=17300 comm="/usr/bin/python3 -u /opt/pilot/bleMainloop ") interface="org.freedesktop.DBus.Objec
>>> tManager" member="GetManagedObjects" error name="(unset)" requested_reply="0" destination=":1.2" (uid=0 pid=1373 comm="/usr/lib/bluetooth/bluetoothd
>>> -d -E --noplugin=* “)
>
> These interfaces have never been blocked, in fact that how
> bluetoothctl access BlueZ so you probably have something wrong with
> your configuration.
>
>>> I see that there’s a bluetooth.conf in /etc/dbus-1/system.d. Do I need to tune something in this file to allow my app to still use the BLE DBus services? Any examples or pointers would be appreciated.
>>>
>>> (sorry if this ended up a repeat post)
I was/am just using the stock debian (stretch) configuration. Except I modify the bluetooth.service to read:
ExecStart=/usr/lib/bluetooth/bluetoothd -d -E --noplugin=*
In the end, rather than modifying any config files though, I found that if add my non-root user to the bluetooth group, that things work fine. The mentioned config file has an entry that hinted me in that direction.--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
