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

[Jamie Strandboge]

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. :)

-- 
Jamie Strandboge             | http://www.canonical.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20160502/8b8d2f64/attachment.pgp>