/dev/shm, /var/tmp and confined snaps

[Sergio Schvezov]

Thank you for the prompt reply!

El 02/05/16 a las 13:31, Jamie Strandboge escribió:
> On Mon, 2016-05-02 at 12:28 -0300, Sergio Schvezov wrote:
> > I'm currently working on an electron based snap (which underneath uses
> > chromium) for vscode. After some debugging and tickling here and there I
> > have a nicely, almost, working snap.
> >
> > One of the things preventing me from chanting out blind success is the
> > fact that for this to work straight out of the box (also read as sans
> > --devmode toggles) is the fact that I would need to patch chromium (the
> > one pulled in by vscode) to make this work.
> >
> > This has got me thinking, and consider me a total ignorant to how
> > /dev/shm works, but wouldn't it be possible to somehow do the same thing
> > we do for /tmp with the ubuntu-core-launcher, that is, create a mount
> > for /dev/shm and while we are at it, one for /var/tmp?
> > This may or may not work.
> >
> For context for others, apps currently have access to
> /dev/shm/snap/<name>/<revision> (though I think we will lose revision here) if
> they want to use shm, but your issue is that apps are hardcoding /dev/shm (or
> /run/shm) somewhere and you have to patch to adjust the path to use the proper
> snap directory. The path for vscode is something that we've had an open bug for
> in oxide (LP: #1260103) for some time (oxide also uses the chromium content
> API).
>
> /dev/shm is a memory backed filesystem and as such it is probably not something
> we would want to setup per app (as in, not a slice of memory for each app), but
> in theory we could create /dev/shm/snap/<name> and bind mount that on /dev/shm
> for the app like we do for /tmp. This would work for some things and break
> others (for example, sdoc apps wanting to use pulseaudio would lose access to
> the required shm files to use pulseaudio).
>
> As for /var/tmp-- it was an active decision in 15.04 that /var/tmp would not be
> supported in snaps and that they would need to be adjusted to use /tmp instead.
> In practice this works out fine because many existing apps try /tmp first,
> /var/tmp second, TMPDIR next, etc and /tmp is almost always the first tried and
> our handling for /tmp covers that. /var/tmp is a pretty specialized though. From
> the FHS: "The /var/tmp directory is made available for programs that require
> temporary files or directories that are preserved between system reboots.
> Therefore, data stored in /var/tmp is more persistent than data in /tmp." IMHO,
> just use SNAP_DATA or SNAP_DATA_USER if your data should persist. We have no bug
> reports on /var/tmp at this time and if this were to change I think we need an
> architect to comment.
>
> > The other idea danlging in my mind for /dev/shm was to have apparmor do
> > more work, and allow any file creation in /dev/shm, tag it while created
> > with the profile and only allow reading if it was "tagged" by the same
> > profile.
> >
> Proper shared memory handling is something that is planned for AppArmor but it
> is pretty far down the list in terms of priorities (since existing file
> mediation covers a fair bit of it). What you describe is sort of what we might
> implement where you say 'anything with this label can access this shared memory'
> (similar to how we handle unix rules).
>
> > Would any of these work? I would consider it a big win if it allowed me
> > not to patch the world, specifically for these two things which don't
> > really require persisting data :-)
>
> I suggest in the short term you file a bug with snapd-interface tag.
>
> Perhaps we would add the necessary path to an existing interface (eg, unity7) or
> a new one (eg, 'chromium'). Alternatively, Gustavo was talking about adding an
> interface for arbitrary paths-- this could also fit into that.
>
> Basically, file a bug and we can discuss it there. :)
>
Ok, I've created https://bugs.launchpad.net/snappy/+bug/1577514
Let's move discussion to the bug.