snap fails because XDG_RUNTIME_DIR is set to /run/user/1000

We need this for dconf.

See https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html for info about the general requirements for the directory.

In particular, for dconf's case:

  - a new directory should be created when an app is run, and it should be shared
    between instances of that app (to the extent that this makes sense in the snappy world)

  - the app should not be able to see the external XDG_RUNTIME_DIR

  - the directory that is created (or some part of it) needs to be visible to the outside world
    flatpak does this by bindmounting XDG_RUNTIME_DIR/app/appid/ such that this directory is the
    same on the inside and outside.

On Touch we set the XDG_RUNTIME_DIR to a subdir of /run/user/*/..., had apparmor policy to allow that and created the directory for the app so it was always there. This has worked well for several years.

As such, it seems that a bind mount is not strictly necessary and on snappy we could:
1. add the apparmor rule: owner /run/user/*/snap.$SNAP_NAME/** mrwklix,
2. have snap run set XDG_RUNTIME_DIR=/run/user/$UID/snap.$SNAP_NAME/
3. have snap-confine mkdir XDG_RUNTIME

and then leave it at that. I believe this solves the dconf case. If a bind mount is determined to be required (I don't think it is and generally prefer to keep these to a minimum to keep things simpler, but please speak up if I'm missing something as to why it is required), then we simply tweak '1' accordingly (ie, owner /run/user/*/** mrwklix,) and add a 4th step to perform the bind mount.

The proposed solution would be great, but one tweak would be nice: instead of putting snap.$SNAP_NAME directly into the XDG_RUNTIME_DIR, consider creating a new subdirectory, to avoid cluttering the top-level.

There is one additional problem: if this is simply a subdirectory of the user's primary XDG_RUNTIME_DIR, it opens up the chance for the snap to easily DoS the rest of the system by filling up that directory. This is why we mount a separate tmpfs for each user, for example.

The DoS is an interesting point but it is difficult to solve generally in that when creating a per-snap tmpfs, we must choose a default size and that feature would need design (note, snaps already have the ability to fill up the tmpfs by creating different files in /run and we've said that resource exhaustion would be handled via store reviews).

To unblock this bug I think we should focus on the plan I outlined but keep your point in mind as a future enhancement. Thanks!

FYI, the changes to snapd are committed and there is an open PR for snap-confine.

same happened with me when i was packing my nwjs application ,

= AppArmor =
Time: Dec 20 20:21:47
Log: apparmor="DENIED" operation="mknod" profile="snap.simple-gulp.messenger-snap" name="/dev/shm/.io.nwjs.MMIb0o" pid=9069 comm="Chrome_IOThread" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
File: /dev/shm/.io.nwjs.MMIb0o (write)
Suggestion:
* adjust program to create files and directories in /dev/shm/snap.$SNAP_NAME.*

How to fix this ??

2.20 fixes this issue.

This is properly set, but... Now the dir isn't created by default.
Shouldn't this be done on launch?

Apps that have this environment variable set, expects the path to be there (as normally it is in a location that the user can't edit /run/user)...

marco@ubuntu-vmware:~:0$ snap run --shell test-snap
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

marco@ubuntu-vmware:/home/marco$ echo $XDG_RUNTIME_DIR
/run/user/1000/snap.qt5-systray
marco@ubuntu-vmware:/home/marco$ ls $XDG_RUNTIME_DIR
ls: cannot access '/run/user/1000/snap.qt5-systray': No such file or directory

Should I open a new bug for this?