Comment 3 for bug 1476781

Currently neither the /usr/lib/telepathy/mission-control-5 nor the /usr/lib/telepathy/telepathy-ofono allow read access to /system/build.prop or dev/socket/property_service, so I'm not sure how this ever worked.

Notice that 'dev/socket/property_service' is missing the leading '/' which means that to add a rule for it, we would have to do something like:
--- telepathy-mission-control-5-5.16.3/debian/apparmor-profile 2015-02-02 01:43:56.000000000 -0600
+++ telepathy-mission-control-5-5.16.3/debian/apparmor-profile 2015-07-21 14:10:51.000000000 -0500
@@ -3,7 +3,7 @@

 #include <tunables/global>

-/usr/lib/telepathy/mission-control-5 {
+/usr/lib/telepathy/mission-control-5 (attach_disconnected) {
     #include <abstractions/base>
     #include <abstractions/dbus>
     #include <abstractions/dbus-session>
@@ -59,6 +59,10 @@
     /usr/share/accounts/services/ r,
     /usr/share/accounts/services/** r,

+ # Ubuntu Touch
+ /dev/socket/property_service rw,
+ @{PROC}/cmdline r,
+
     # Site-specific additions and overrides. See local/README for details.
     # Please note that accesses in local/usr.lib.telepathy are also applied to
     # /usr/lib/telepathy/telepathy-*.

'attach_disconnected' is something I'd like to avoid since it is at best a workaround for a limitation in apparmor (that we are working on but won't be fixed for a while). As such, I'd prefer that we "add rild.libpath to build.prop" if that doesn't have any other repercussions.

If we do that, will read access need to be granted to /system/build.prop? If you are going the rild.libpath route, please paste the denial and I can fix the profile accordingly.

Thanks!