Fine-grained dbus policy for applications

[Dylan McCall]

I am working on a flatpak for an application which needs to interact with a dbus service with a large number of interfaces. The application only needs to use with a small amount of the stuff exposed by this service, so using --talk-name=scary.service.with.lots.of.power in flatpak-build-finish is not ideal.

For what it's worth, I do intend to contribute a portal to avoid using the big scary service, but there other flatpak applications which talk with dbus services in this way and portals are kind of a piece-meal solution. (Depending on the specificity of a given problem, I dare say they might not even apply in every case, although they are effective most of the time).

So, is there a way to set a more fine-grained dbus policy in a flatpak manifest? This would allow me to do the next best thing in lieu of a portal. I see xdg-dbus-proxy has a mechanism for more specific rules beyond "talks to name" (https://github.com/flatpak/xdg-dbus-proxy/blob/master/flatpak-proxy.c#L517-L604). I see how this is used for *built in* flatpak things, and how I assume it could fit into flatpak_context_to_args and flatpak_context_add_bus_filters (https://github.com/flatpak/flatpak/blob/master/common/flatpak-context.c#L1982-L2073).

I am wondering if there is an argument to be made for adding something like a --call=NAME=RULE option to flatpak-build-finish, or extending the syntax for --talk-name with something like --talk-name=com.example.Service at com.example.Interface.Method@/com/example/object.

And also, of course, I am also wondering if this argument has already happened :)

Dylan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/flatpak/attachments/20201204/a90144ad/attachment.htm>