Add qml-module-qtbluetooth support

Bug #1526836 reported by Pat McGowan on 2015-12-16
18
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Canonical System Image
High
Pat McGowan
apparmor (Ubuntu)
Undecided
Jamie Strandboge
content-hub (Ubuntu)
Undecided
Unassigned
ubuntu-touch-meta (Ubuntu)
High
Łukasz Zemczak
ubuntu-touch-meta (Ubuntu RTM)
High
Łukasz Zemczak

Bug Description

Add to the seed
Make available in the ota9 framework
Add apparmor policy

API reference at http://doc.qt.io/qt-5/qtbluetooth-index.html

Changed in canonical-devices-system-image:
assignee: nobody → Pat McGowan (pat-mcgowan)
importance: Undecided → High
milestone: none → ww02-2016
status: New → Confirmed
Changed in apparmor (Ubuntu):
assignee: nobody → Jamie Strandboge (jdstrand)
Changed in ubuntu-touch-meta (Ubuntu RTM):
status: New → Confirmed
Changed in ubuntu-touch-meta (Ubuntu):
status: Confirmed → In Progress
Changed in ubuntu-touch-meta (Ubuntu RTM):
importance: Undecided → High
assignee: nobody → Łukasz Zemczak (sil2100)
Jamie Strandboge (jdstrand) wrote :

What does 'add apparmor policy' entail? What does qml-module-qtbluetooth use on the backend? Will it support trust-store prompting (and therefore be a 'common', safe policy group) or will it be an unsafe, 'reserved' policy group (eg, like 'contacts' is today)?

Changed in ubuntu-touch-meta (Ubuntu RTM):
status: Confirmed → Fix Released
Changed in ubuntu-touch-meta (Ubuntu):
status: In Progress → Fix Committed
description: updated
Michael Zanetti (mzanetti) wrote :

Some info:

The backend for the module is shipped with QtConnectivity, hence doesn't have any trust prompts around. That backend will talk to BlueZ over D-Bus on the system bus for the most part. Additionally, OBEX & RFCOMM (the two most interesting profiles for a start) read from/write to unix file descriptors to exchange data with the remote device. Those files are created by bluez and the descriptors handed over to the app in order to read from/write to it. Reading through the code, file transfers also seem to require temporary files on its own.

http://code.qt.io/cgit/qt/qtconnectivity.git/tree/src/bluetooth/qbluetoothtransferreply_bluez.cpp

What subset exactly is to be opened on the system D-Bus, I don't know exactly atm. However, I do have a Content-Hub plugin and a proof of concept service for sharing files (both, sending and receiving) around in here:

https://code.launchpad.net/~mzanetti/+junk/ubtd (They were created back in the days with Bluez4 and will require some updating to work with Bluez5 but I think they can make good examples or even be the start for the BT file sharing implementation we will need).

I think the OBEX file sending/receiving will definitely needed to be implemented in the system, and with that can be unconfined/trusted. That said, we might want to allow apps doing so too, but I think that's not sooo critical for a start.

The RFCOMM/L2CAP on the other hand is really something that Apps will want to use. That's the basis for things like multiplayer BT games, BT remote controlling stuff or also connecting to any other BT enabled gadget.

When it comes to Low Energy, my experience gets a little thinner, but looking at the QtBluetooth backend implementation it seems to be the same as RFCOMM. It requests a L2CAP socket (in form of a file descriptor) exchanges data through that.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in apparmor (Ubuntu):
status: New → Confirmed
Jamie Strandboge (jdstrand) wrote :

It sounds like the content-hub portion can just be handled with changes to content-hub and the app doesn't need anything new.

OBEX file sending/receiving sounds like it doesn't need app policy at this time. That service can just run trusted (though it would be nice if it ran confined with a system profile since it will be handling untrusted input).

I need more details on RFCOMM/L2CAP and Low Energy-- how are apps supposed to use this? What would apparmor policy for apps look like? How do apps get access to the devices-- are they files in the filesystem? Are they virtual kernel devices? How do apps find out about them? How are they assigned? How can we integrate the trust-store for this sort of thing?

Changed in apparmor (Ubuntu):
status: Confirmed → Incomplete
Changed in canonical-devices-system-image:
milestone: ww02-2016 → ww08-2016
Changed in ubuntu-touch-meta (Ubuntu):
status: Fix Committed → Fix Released
Changed in canonical-devices-system-image:
status: Confirmed → Fix Committed
Changed in canonical-devices-system-image:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers