snap fails because XDG_RUNTIME_DIR is set to /run/user/1000
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/
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=
File: /run/user/
Suggestions:
* adjust program to use $SNAP_DATA
* adjust program to use /run/shm/
Searching in the mailing list, there is a suggestion from John from one year ago, to give a runtime dir to every package: https:/
To reproduce:
$ git clone https:/
$ cd keybase
$ git checkout snapcraft
$ sudo apt install snapcraft
$ snapcraft
$ sudo snap install keybase*.snap
$ keybase status
tags: | added: snapd-interface |
Changed in snappy: | |
status: | New → Triaged |
affects: | snappy → snap-confine |
Changed in snap-confine: | |
importance: | Undecided → High |
assignee: | nobody → Zygmunt Krynicki (zyga) |
desrt (desrt) wrote : | #1 |
Jamie Strandboge (jdstrand) wrote : | #2 |
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/
2. have snap run set XDG_RUNTIME_
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.
desrt (desrt) wrote : | #3 |
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.
desrt (desrt) wrote : | #4 |
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.
Jamie Strandboge (jdstrand) wrote : | #5 |
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 |
Jamie Strandboge (jdstrand) wrote : | #6 |
FYI, the changes to snapd are committed and there is an open PR for snap-confine.
Changed in snappy: | |
status: | In Progress → Fix Committed |
Changed in snap-confine: | |
milestone: | none → 1.0.45 |
status: | In Progress → Fix Committed |
Changed in snap-confine: | |
milestone: | 2.19 → none |
no longer affects: | snapd (Ubuntu) |
keshavbhatt (keshavnrj) wrote : | #7 |
same happened with me when i was packing my nwjs application ,
= AppArmor =
Time: Dec 20 20:21:47
Log: apparmor="DENIED" operation="mknod" profile=
File: /dev/shm/
Suggestion:
* adjust program to create files and directories in /dev/shm/
How to fix this ??
Jamie Strandboge (jdstrand) wrote : | #8 |
2.20 fixes this issue.
Changed in snappy: | |
status: | Fix Committed → Fix Released |
Changed in snap-confine: | |
status: | Fix Committed → Fix Released |
Marco Trevisan (Treviño) (3v1n0) wrote : | #9 |
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-
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
marco@ubuntu-
/run/user/
marco@ubuntu-
ls: cannot access '/run/user/
Should I open a new bug for this?
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 DIR/app/ appid/ such that this directory is the
flatpak does this by bindmounting XDG_RUNTIME_
same on the inside and outside.