@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 bluetooth policy 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 network and bluetooth policy 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 .apparmor file provided with my app, but clickable didn't seem to approve
