I fully agree. I was thinking about some avenues. I was thinking about a hotplug-like interface that would allow access to specific places (e.g. project directory) so that a command line toolchain can be used on it. Desktop apps could use it as well, especially deeply integrated things like atom/vscode. For more casual apps where you don’t typically work with thousands of files I think the portal approach is better (a trusted helper moves the file from host to app) but this is obviously hanging on integration into electron runtime itself.
3 Likes
I think we can somewhat easily integrate that problem into the conversation we’re having about overmounts.
My hotplug idea would not require any filesystem changes. It would just expose a way to create instances of slots that could be plugged to snaps to allow them to read certain areas. If we go to a mount-based approach we could offer read-only or read-write bind mounts so that the tree structure would look nicer.
For example one can create some zones:
~/Documents/Code -> Documents-Code
~/Music -> Music
~Photos -> Photos
and then connect them to individual application:
files:documents-code atom:files
files:music spotify
files:photos shotwell
We could then create something under $SNAP_COMMON for such snaps, e.g. $SNAP_COMMON/files/Photos and that would be a bind mount of the real photos. This solution feels a bit hackish to me (UX would be hard to get right for desktop stuff) but has the potential to work well with complex and headless apps. Still, just an idea in the back of my head. Something I wanted to share.
It should work well out of the box without people having to do manual assignments like this.
Editors are special because we want to use them in arbitrary locations in the filesystem. For files in $HOME, we already have the home interface which solves the problem, so we should encourage using that when content is mainly there.
Let’s think through this after we’re done with snap-update-ns, as this is a natural pre-requirement of most interesting things we can do in that space.
2 Likes
I think lots of tooling (like text editors) that requires read/write access to the entire filesystem would benefit from the runtime isolation of being confined, even if from a security pov it would be the same as a classic snap.
I also think it would be great if the operator could grant filesystem permission for a subtree to a confined snap (eg. granting access to /var/log/foo to store logs in a common place, or $HOME to be able to edit all files including hidden).
One idea I’ve been thinking off is to allow the snap to define a pattern that is matched against the command line.
Vaguely, something along the lines of:
command: bin/vim [<path>]
or, an analogous example with a configuration file:
command: mydaemon [--config <path>]
When the given application is run, the provided path is both unconfined and translated into the correct location for the snap to see it.
This is not a general solution, since the editor would not be able to observe paths that were never seen, but it solves a class of those issues elegantly and transparently for the user.
Not something we’ll work on today, but an interesting idea to evolve.
If I plug in the Home interface into my snap at build time, would it also have write permissions?
Considering editors need only parts of the filesystem, maybe instead of a classic confinement, one can confine the snap strict if plugging in Home grants write permissions. Until such a time a build time hack / solution is found.
Also, I see the content interface opening up slots (see content in the table). However, snap interfaces doesn’t list the slots for content interface.
Even if it does, the core snap only sees /var/ for instance. If an editor should require rw access to the document root of a web server usually under var/www/ , how would the core expose something it doesn’t see?
@retrocausal Yes, the home interface includes writing, and it’s indeed what enables many of the usual applications that need access to the user’s home to work okay when confined.
The problem with editors is that often people do care about reading and writing things that are in restricted spaces, so while having access to home solves part of the problem, it’ll eventually be quite frustrating.
It does list it. Are you seeing a case where it doesn’t? That would be a bug.
The core snap conceptually includes snapd itself. It can affect how the overall system works.
1 Like
Yeah, when I run
snap interfaces
on my system, I do not see slots for content listed . I am running core 16-2.26.14
fresh installation.
So, would it be proper to assume, that If I use the content interface and plug into its slots,
my snap can read / write on all writable targets exposed by core?
Is there a default list of locations the core exposes as writable?
Do you have an example where snap interfaces does that? It seems to work fine here.
The content interface only exposes what was specifically exported by that content interface. See the documentation for details.
1 Like
which snaps do you have installed that should provide content ? (might be bugs in these snaps, without a snap providing any content you will indeed not see any content interfaces)
Well, I am just looking to see, if the core snap exposes/provides any content.
I want my snap which is an editor, to be able to plug into content exposed by core itself.
the case being,
- If I want to edit files under
/var/wwwvia my editor, - And the core provides such writable slot,
- plug into the writable slot, so users can edit files under
/var/www
So, Installing snapd installs the core snap, and I am wondering if it should provide for write access to some default content locations
well, thats not a content interface (which implies something (a lib, binaries, icons, themes or fonts etc) is shared from another snap) but a simple file access thing …
not sure if there is anything planned in that regard, code wise it would just be a copy of the home interface with the paths adjusted i guess
1 Like
gotcha! just want to avoid confining snaps as classic unnecessarily for want of access to limited filesystem locations 
2 Likes