This needs someone to write the interface and submit it. Note this will definitely be a privileged interface until someone works with upstream to make the services enforce application isolation. AIUI, this work is unprioritized. Please escalate via the stakeholder process if this should be prioritized over current work.
I don’t know what this would look like, but @jamesh is right-- we can’t allow exactly what is described here in the forum without it being a privileged interface because it gives a direct path to confinement escape. @Trevinho mentioned session services but this is a bit different. We definitely do need session services but this functionality is about starting a non-daemon automatically on login (though admittedly, if we had session services the snap could write a session service that could start an application in the user’s session if
$SNAP_USER_DATA/.config/autostart/foo was present). In addition to the security issues outlined above, each DE seems to handle this differently. This needs design so applications can use a consistent interface that works across DEs.
I suspect it is something similar to how we handle desktop files: the snap puts a desktop file somewhere in the snap, and snap run provides a facility that the application can use (snapctl? dbus session service?) to request putting a sanitized version of that file in place. For existing applications, the desktop part could help: we know that $HOME is set to $SNAP_USER_DATA, the snap is allowed to write whatever it wants there, including to $SNAP_USER_DATA/.config/autostart. The desktop part could check if this file exists and if it does, use the aforementioned facility (snapctl? dbus session service?) to put the sanitized version in place. Or, the desktop part could use the session service idea (above).
Again, these are just otoh idea and needs design.
Can you verify this is still broken? I verified that https://bugs.launchpad.net/snapd/+bug/1663565 is fixed. If those fixes were incomplete, please file a new bug.