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

Bug #1620442 reported by Leo Arias on 2016-09-06
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Snappy
High
Jamie Strandboge
snap-confine
High
Jamie Strandboge

Bug Description

I'm trying to snap the keybase.io go client. I can build it properly, but when I try to run the commands it fails like this:

$ keybase status
▶ WARNING Running in devel mode
▶ ERROR dial unix /run/user/1000/keybase.devel/keybased.sock: connect: no such file or directory

Looking at the source code, it's trying to write to $XDG_RUNTIME_DIR, which is:

$ echo $XDG_RUNTIME_DIR
/run/user/1000

And the snap doesn't have permission to write to that directory:

Log: apparmor="DENIED" operation="mkdir" profile="snap.keybase.keybase" name="/run/user/1000/keybase.devel/" pid=8381 comm="keybase" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
File: /run/user/1000/keybase.devel/ (write)
Suggestions:
* adjust program to use $SNAP_DATA
* adjust program to use /run/shm/snaps/$SNAP_NAME/$SNAP_REVISION

Searching in the mailing list, there is a suggestion from John from one year ago, to give a runtime dir to every package: https://lists.ubuntu.com/archives/snappy-devel/2015-August/001009.html

To reproduce:

$ git clone https://github.com/elopio/client
$ cd keybase
$ git checkout snapcraft
$ sudo apt install snapcraft
$ snapcraft
$ sudo snap install keybase*.snap
$ keybase status

Zygmunt Krynicki (zyga) on 2016-09-06
tags: added: snapd-interface
Changed in snappy:
status: New → Triaged
John Lenton (chipaca) on 2016-10-18
affects: snappy → snap-confine
Changed in snap-confine:
importance: Undecided → High
assignee: nobody → Zygmunt Krynicki (zyga)
Revision history for this message
desrt (desrt) wrote :

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.

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

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.

Revision history for this message
desrt (desrt) wrote :

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.

Revision history for this message
desrt (desrt) wrote :

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.

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

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!

Changed in snap-confine:
assignee: Zygmunt Krynicki (zyga) → Jamie Strandboge (jdstrand)
status: Triaged → In Progress
Changed in snappy:
assignee: nobody → Jamie Strandboge (jdstrand)
importance: Undecided → High
status: New → In Progress
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

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

Changed in snappy:
status: In Progress → Fix Committed
Zygmunt Krynicki (zyga) on 2016-11-24
Changed in snap-confine:
milestone: none → 1.0.45
status: In Progress → Fix Committed
Zygmunt Krynicki (zyga) on 2016-12-08
Changed in snap-confine:
milestone: 2.19 → none
no longer affects: snapd (Ubuntu)
Revision history for this message
keshavbhatt (keshavnrj) wrote :

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 ??

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

2.20 fixes this issue.

Changed in snappy:
status: Fix Committed → Fix Released
Changed in snap-confine:
status: Fix Committed → Fix Released
Revision history for this message
Marco Trevisan (Treviño) (3v1n0) wrote :

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?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers