This looks like a good candidate for the "desktop" interface. Security is significantly better than the traditional IBus communication method, since access to IBusContexts are restricted to their owner:
https://github.com/ibus/ibus/blob/master/portal/portal.c#L354-L370 ... and IBusContext signals are unicast to the owner rather than broadcast: https://github.com/ibus/ibus/blob/master/portal/portal.c#L408-L414 Further more, IBus's non-portal communication method goes over a separate socket connection. So any session bus rules we add should not inadvertently provide access to the insecure API. I would also consider merging the last two proposed rules into one like so: dbus (send, receive) bus=session path=/org/freedesktop/IBus/InputContext_[0-9]* interface=org.freedesktop.IBus.InputContext peer=(label=unconfined), It doesn't look like there is any methods with different level of privilege on the interface, and this avoids incompatibilities if IBus evolves in future. We probably also want to allow communication with peer=(name=org.freedesktop.portal.IBus) for the base CreateInputContext API, since the service file does not contain an AssumedAppArmorLabel field that would allow service activation to succeed otherwise. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1881232 Title: AppArmor blocks ibus input when IBUS_USE_PORTAL=1 To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1881232/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
