Read/write access to /tmp

snapcraft
1

Hi,
first of all apologies, I am a new user of snap/snapcraft and I might be asking a stupid question here, so please bear with me.

I have successfully created a snapped application in strict confinement mode, let’s call it “mynap.foo”. The workflow is as following:

  • I transfer some files to the /tmp folder, let’s say to /tmp/bar. Note that the actual name of the folder is determined at runtime - it involves a timestamp, i.e. is something like /tmp/bar-2020-12-24-00-00-00.
  • I try to mysnap.run foo to work on the transferred files in /tmp/bar. However mysnap.foo now says the files are empty, which I assume is just saying that foo does not have read access.
  • mysnap.foo should also have write access to /tmp/bar since it would leave output files there

Is there an easy way to achieve this? I definitely want to keep the strict confinement, and if possible I don’t want to make changes which would require the snapcraft team to review the application manually.

Currently used plugs are:
plugs:
account-control:
audio-playback:
cups-control:
desktop:
desktop-legacy:
gsettings:
hardware-observe:
home:
network:
network-control:
network-observe:
opengl:
removable-media:
shutdown:
ssh-keys:
x11:

Output from snappy-debug scanlog is as follows; note the first error is definitely unrelated and doesn’t pose a problem:

= AppArmor =
Time: Dec 18 07:38:15
Log: apparmor=“DENIED” operation=“open” profile=“snap.mysnap.foo” name="/var/lib/snapd/hostfs/usr/lib/x86_64-linux-gnu/libOpenGL.so.0.0.0" pid=18989 comm=“Sigurd” requested_mask=“r” denied_mask=“r” fsuid=1000 ouid=0
File: /var/lib/snapd/hostfs/usr/lib/x86_64-linux-gnu/libOpenGL.so.0.0.0 (read)
Suggestions:

  • adjust program to read necessary files from $SNAP, $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON
  • adjust snap to use snap layouts (Snap layouts)

= AppArmor =
Time: Dec 18 07:38:15
Log: apparmor=“DENIED” operation=“dbus_method_call” bus=“session” path="/org/a11y/bus" interface=“org.freedesktop.DBus.Properties” member=“Get” mask=“send” name=“org.a11y.Bus” pid=18989 label=“snap.mysnap.foo” peer_pid=3018 peer_label=“unconfined”
DBus access

2

Strict snaps run with private /tmp setups, so each snap has a separate /tmp which is not the same as that of the host. In fact, the /tmp for a snap is a sub directory of the host’s /tmp directory.

3

The normal settings for /tmp are 1777, which ls shows as drwxrwxrwt. That is: wide open, except that only the owner of a file can remove it (that’s what this extra t bit means for a directory).

The problem with a /tmp with mode 777 is that another user could remove a file that you’ve created and substitute the content of their choice.

If your /tmp is a tmpfs filesystem, a reboot will restore everything. Otherwise, run chmod 1777 /tmp.

Additionally, a lot of files in /tmp need to be private. However, at least one directory critically needs to be world-readable: /tmp/.X11-unix, and possibly some other similar directories (/tmp/.XIM-unix, etc.).