Trying to revive 'ubtd' (Bluetooth file transfer)
-
@gpatel-fr said in Trying to revive 'ubtd' (Bluetooth file transfer):
Great ! have happy file exchanges with your car
That won't work yet, unfortunately. For this, I need the SharePlugin to work. That one still crashes as soon as I select it which causes the phone to restart.
More troubleshooting needed
-
@lduboeuf said in Trying to revive 'ubtd' (Bluetooth file transfer):
Congrats, So some changes are needed on UT to make it work ?
If your question is: did I need to hack my phone to make the app work in its current state, then the answer is no. As suggested by @gpatel-fr, I just gave it an "unconfined" AA profile (which I understand would prevent me from publishing it on the OpenStore).
So eventually an updated
bluetoothAppArmor Policy Group would be needed, I guess (or a extra one dedicated to OBEX). -
@PhAndersson I think any spawning of external processes that are not inside the app's
~/.local/sharedirectory require unconfined. And in this case, unconfined would be required since it's using some system executable. -
@projectmoon said in Trying to revive 'ubtd' (Bluetooth file transfer):
I think any spawning of external processes that are not inside the app's ~/.local/share directory require unconfined.
If 'running an external process' means 'activating a service' via dbusk, not 'spawning', it can be done from confined I think. I did not check how exactly is working this application.
-
@PhAndersson said in Trying to revive 'ubtd' (Bluetooth file transfer):
prevent me from publishing it on the OpenStore
Not sure of that actually, there are applications with a big red scary warning, that do not prevent them to be published.
Also, IIRC the idea on phone OS is that the app is shipped with granular authorizations policy and the user grant these rights or not. I don't see why you could not ship a granular apparmor policy for the app if you wanted to do so.
-
@gpatel-fr said in Trying to revive 'ubtd' (Bluetooth file transfer):
@PhAndersson said in Trying to revive 'ubtd' (Bluetooth file transfer):
prevent me from publishing it on the OpenStore
Not sure of that actually, there are applications with a big red scary warning, that do not prevent them to be published.
Also, IIRC the idea on phone OS is that the app is shipped with granular authorizations policy and the user grant these rights or not. I don't see why you could not ship a granular apparmor policy for the app if you wanted to do so.
For such application to be exposed to the Openstore one will have to ask the Openstore team for validation/ review
-
@gpatel-fr said in Trying to revive 'ubtd' (Bluetooth file transfer):
@projectmoon said in Trying to revive 'ubtd' (Bluetooth file transfer):
I think any spawning of external processes that are not inside the app's ~/.local/share directory require unconfined.
If 'running an external process' means 'activating a service' via dbusk, not 'spawning', it can be done from confined I think. I did not check how exactly is working this application.
Yes, that was my experience as well. Even with an enforcing AA profile, my app was able to ask D-Bus to start the OBEX daemon if needed.
Only certain types of D-Bus requested are blocked by AA (such as
AuthorizePush-- see log extract in one of my posts above). -
@PhAndersson said in Trying to revive 'ubtd' (Bluetooth file transfer):
certain types of D-Bus requested are blocked by AA (such as AuthorizePush
I have actually taken a look at the ubtd code and as I understand it AuthorizePush is a method defined by ubtd for obex.
Looking at the Ubuntu touch bluez code with some dismay, it seems that this method is defined quite officially to allow the obex daemon to send data to a client, squarely fitting your use case, so why is there no apparmor policy for that ? As a wild guess, it looks like an oversight by Canonical that was forwarded by Ubuntu Touch - or even an oversight by Debian, forwarded by Canonical, forwarded by Ubuntu Touch. Maybe a bluetooth policy should exist.
Or maybe it already exists ? looking at usr.sbin.cupsd in my Kubuntu 24.04 installation, I see a string 'network bluetooth'. Maybe adding that to your apparmor profile could strike gold ? Absolutely wild guess of course
-
@gpatel-fr said in Trying to revive 'ubtd' (Bluetooth file transfer):
@PhAndersson said in Trying to revive 'ubtd' (Bluetooth file transfer):
certain types of D-Bus requested are blocked by AA (such as AuthorizePush
I have actually taken a look at the ubtd code and as I understand it AuthorizePush is a method defined by ubtd for obex.
Correct -- it's still present in my current code.
Looking at the Ubuntu touch bluez code with some dismay, it seems that this method is defined quite officially to allow the obex daemon to send data to a client, squarely fitting your use case, so why is there no apparmor policy for that ? As a wild guess, it looks like an oversight by Canonical that was forwarded by Ubuntu Touch - or even an oversight by Debian, forwarded by Canonical, forwarded by Ubuntu Touch. Maybe a bluetooth policy should exist.
Well, there is a
bluetoothpolicy group, and I used it. But it doesn't seem to cover that use case.Or maybe it already exists ? looking at usr.sbin.cupsd in my Kubuntu 24.04 installation, I see a string 'network bluetooth'. Maybe adding that to your apparmor profile could strike gold ? Absolutely wild guess of course
If you refer to the
networkandbluetoothpolicy groups, I already use both (as you will see in one of my earlier posts), but that was not enough.If there is a way to extend an app AA profile past the predefined policy groups offered by the platform, I would be interested. Can you point me to a doc. that covers it? I already tried hacking the
.apparmorfile provided with my app, butclickabledidn't seem to approve -
My knowledge of apparmor is basic unfortunately. In particular, interaction with dbus is something I never looked at before UT, and bluetooth and network management with apparmor is totally unknown to me.
Yes my suggestion of using network bluetooth was not very well thought out, I was believing that maybe there was special in associating the two, as if there was a right called network_bluetooth. My bad
This said, there is something that bothers me in your log: it suggest that there is a denial in the sending FROM the server (the systemd service) TO your app. Usually when a sending is denied, it is the sender that is lacking rights.
So following this idea, it could be the system itself that is missing a configuration. However, see above, I have no idea how rights are managed for the bluetooth services.
Maybe all that is needed is to add an apparmor profile for the obexd executable, but often the obvious solution is wrong.
Note that if you want to test it, there is no need to turn your rootfs r/w, with overlay or bind-root you can 'add' stuff in read only directories.Sorry not to be more specific, but going deep in system administration takes time and concentration and I'm currently in other stuff.
