The reason why GNOME apps (and others) do this is to communicate with arbitrary apps within the user's session. This is because the old world uses a distro model that assumes a trusted archive and therefore everything in the user's session is trusted and everything can do anything to interoperate. Of course, the new world changes that, apps are not trusted by the system and must communicate via defined interfaces. We are going to continue to bump up against applications designed for the old world trust model when running them in the new world.
All that said, I was thinking the same thing Gustavo was-- we definitely can add a dbus bind rule to the unity7 interface and Gustavo is right that simply binding does not allow communication. The only problem then is controlling what the app can bind to, which is what Mark's idea tries to address. We could simply not care but this would mean that an app could perform a DoS against other apps or against session services by binding to names it shouldn't. I'm not sure of the proper solution for this but was thinking along the same thing Mark was-- limiting it somehow to the snap name and likely in a separate interface with an attribute. This is actually pretty similar in concept to what we did in snappy 15.04 with 'bus-name' but what we found with 'bus-name' is that the well-known bus name that existing applications use not the same as the snap name. In this particular example, the snap name is gnome- mahjongg but the dbus name is org.gnome.gnome-mahjongg. Since this is mostly something with GNOME apps, we could call this 'gnome-app-bind' (or something with 'gnome' in the name) and allow binding to org.gnome.<SNAPNAME> which would fix this bug. Of course then we have things like Rhythmbox which binds to several: org.gnome.Rhythmbox3, org.gnome.UPnP.MediaServer2.Rhythmbox, org.mpris.MediaPlayer2.rhythmbox or evolution: org.gnome.Evolution, org.gnome.EvolutionAlarmNotify. There just isn't a standard well-known dbus name naming convention. Ok, so moving forward I think we have a few options: 1. don't worry about name collisions and bind to anything in unity7 2. since we know these are gnome apps, create a gnome dbus interface that allows binds to org.gnome.** 3. come up with a parameterized interface and have snaps declare what to bind to and have snapd refuse installing snaps that collide '2' isn't much of an improvement over '1' based on d-feet output-- there are a ton of session services and apps that start with org.gnome.*. I'm not sure we can do much better than '3' with these old world apps. If parameterized interfaces are a ways off and we want to do '3', I suggest implementing the interface without parameters (ie, the default) that allows binding to anything today. Then when the parameterized bits are added, we adjust the review tools to trigger a manual review if the snap doesn't specify the attribute. In this manner existing apps don't break and apps can transition to using attributes. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1590679 Title: Apps can't own session bus names (unity7 interface) To manage notifications about this bug go to: https://bugs.launchpad.net/snappy/+bug/1590679/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
