I’m trying to figure out what is the situation with a snap application wanting to execute another application provided by the same snap: my understanding is that this is possible, but causes the child process to be started under the same AppArmor profile as the parent (and, I guess, the overall mount namespace and group confinement will be the same?).
This does not appear to be the most desirable situation, because different applications generally use different interfaces, so executing the second application under the same confinement as the first one is likely to miss some accesses. On the other hand, modifying the snap configuration to add all the plugs from the second app to the first app will likely solve this problem, but leads to a non-optimal confinement.
I’ve been searching a bit in the forums and found a few threads related to this issue, with this post being the most interesting I’ve found on the matter. It mentions an apparmor limitation as a blocker, but on the other hand that thread was considering a very specific situation which I’m not sure applies to the generic case.
Getting to the point: would it make sense to have a functionality in snapd (maybe accessible via
snapctl from within a confined snap), so that an application could request the execution of another application coming from the same snap, but have the application started as if the user started it from outside of the snap?