This bug affects usability. If you install a snap and run one of its binaries with 'sudo foo.bar' then /home/ubuntu/apps gets created as root and subsequent commands run as non-root will fail to create their user data directories. I like ted's reasoning but ultimately I don't think we shouldn't second guess the application. There is precedent for this all over the place with (OTOH) ssh, gpg and openssl all creating their dot files/directories under /root when they are run as root.
If the application is intentionally using SNAP_APP_USER_DATA_PATH and is running as root, we should set SNAP_APP_USER_DATA_PATH to /root/apps/<name>/<version>.... This means the launcher needs to change and the apparmor policy.
Adding tasks for those (which we can remove later if others think something else should be done).
This bug affects usability. If you install a snap and run one of its binaries with 'sudo foo.bar' then /home/ubuntu/apps gets created as root and subsequent commands run as non-root will fail to create their user data directories. I like ted's reasoning but ultimately I don't think we shouldn't second guess the application. There is precedent for this all over the place with (OTOH) ssh, gpg and openssl all creating their dot files/directories under /root when they are run as root.
If the application is intentionally using SNAP_APP_ USER_DATA_ PATH and is running as root, we should set SNAP_APP_ USER_DATA_ PATH to /root/apps/ <name>/ <version> .... This means the launcher needs to change and the apparmor policy.
Adding tasks for those (which we can remove later if others think something else should be done).