Comment 11 for bug 1470265

Jamie Strandboge (jdstrand) wrote :

I might not have connected a dot or two on this, so let me mention a couple of other things. Obviously, it is easy fixing aa-clickhook to handle an extra '_' -- apparmor userspace and the kernel certainly doesn't care (the seccomp policy generation would also need to be adjusted similarly). However, other things are affected by this seemingly simple change. Since the apparmor profile name would now allow '_' in the appname, different trusted helpers that look at the the connecting process may parse the profile name in various ways and their parsing would need to be verified and potentially adjusted. Unity8 and UAL application lifecycle would have to be examined since the APP_ID is derived from the package's packaging and it needs to have the APP_ID match the generated profile name. Snappy would have to be adjusted to make sure that the generated systemd units and bin-path can handle the new apparmor profile name. ubuntu-core-launcher looks at the package.yaml to derive the APP_ID and it too needs to have the APP_ID match the generated profile name. The profile name or some subset of it may be used as a key in a trust database (eg, online accounts, trust-store, ...) that may have to be reworked. Scopes would need to be looked at to make sure they are using the correctly named app-specific endpoints. Similarly, apps on Ubuntu Touch have some app-specific directories on the filesystem that use the appname (specifically, scopes, online accounts and QML caching)-- these services and/or policy would have to be revisited to make sure they are doing the right thing with an optionally additional '_'.

Again, it is possible, just a lot of details to get right (hence getting architects' team involvement on if it is worth it and if so, direction on the implementation).