[Feature request]: Allow --filesystem to specify sandbox mount point (similar to docker's -v )

[GavinNL]

Checklist

• [X] I agree to follow the Code of Conduct that this project adheres to.
• [X] I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Suggestion

I was doing some experimentation with some alternative ways of using Flatpak and was looking for a way to bind a host directory at a particular location in the sandbox. I didn't seem to find one. I am using Linux Mint 21.2 with Flatpak version 1.12.7. I believe the latest version is 1.14.4. I wasn't sure if that version added this additional feature already, I checked the documentation and didn't find anything that was similar so I hope I am not asking for something that already exists

The closest thing I could do was add --filesystem=/path/on/host, but this doesn't allow me to specify where in the sandbox the folder would be mounted on. It would be mounted at /path/on/host inside the sandbox as well.

Is it possible to add the ability to mount additional host folders at specified sandbox paths? I have listed 3 possible ways this could work. This would function similar to docker/podman's volume mount option -v /path/on/host:/path/in/sandbox

# Option 1: append additional functionality to --filesystem
flatpak run --filesystem=/path/on/host:/path/in/sandbox:rw,xdg-pictures  --command=bash org.freedesktop.Sdk

# Option 2: new --volume-mount flag for extra mounting options
flatpak run --volume-mount=/path/on/host:/path/in/sandbox:rw,/another/path/on/host:/read/only:ro --filesystem=xdg-pictures  --command=bash org.freedesktop.Sdk

# option 3: --extra-bwrap-args - passed the arguments directly to the final bwrap call 
flatpak run --extra-bwrap-args="--bind /path/on/host /path/in/sandbox --ro-bind /another/path/on/host /read/only" --filesystem=xdg-pictures  --command=bash org.freedesktop.Sdk

Thank you!

[smcv]

Is it possible to add the ability to mount additional host folders at specified sandbox paths?

It is technically possible, but the design of Flatpak intentionally doesn't do this, in an effort to try to minimize the number of places where users get confused by differences between a path inside the sandbox and a path outside.

The general design principle so far has been that either a location from the host is shared with the sandbox, or it is not shared; but if it's shared, it appears in the same place in both views of the filesystem. Exceptions are:

• where that's not technically possible because something more important prevents it, like /usr (for example the host's /usr, if shared, ends up at /run/host/usr instead)
• when an app uses --persist to get a partial or complete private home directory, like for example Steam does

I was doing some experimentation with some alternative ways of using Flatpak and was looking for a way to bind a host directory at a particular location in the sandbox

What was your use case for doing that?

[GavinNL]

Hi Smcv,

There are two immediate use cases that I was experimenting with

Single Binary (appimage style) Executables

I wanted to create a single-file shell+squasfs executable similar to how appimages work, but instead run within a flatpak platform. The self-running shell+squashfs would mount the squashfs part at some folder (usually /tmp/XXXX), and then mount that folder inside the flatpak.

I already have a prototype of this working, but I can only mount the folder in place of /app using --app-path=/tmp/XXXX, having a little more flexibility with where the destination path is mounted would help. I work with OpenGL/Vulkan, having a single binary that I could send to my friends/colleagues to test out would help quite a bit. Since flatpak handles graphics drivers automatically, this would help me with making portable graphics executable without having to create a full flatpak and upload it to a repo.

Overlay Home Folder

The other use case is to create a special home directory using overlay fs, and then mount that folder inside the flatpak. That way the flatpak has writable access to the home directory but doesn't actually make persistent changes, and I can see exactly what changes it was trying to make. eg:

mkdir -p /tmp/overlay/{upper,mount,work}
# Create a overlay mount with the home directory being the lower read-only dir
fuse-overlayfs -o lowerdir=$HOME,upperdir=/tmp/overlay/upper,workdir=/tmp/overlay/work /tmp/overlay/mount

# Run flatpak
flatpak run --filesystem=/tmp/overlay/mount --command=bash org.freedesktop.Platform

# All changes can now be viewed in /tmp/overlay/upper

The above works and gives me a shell inside the flatpak. I can make changes to /tmp/overlay/mount and it works the way I expect it to. I can delete files in there and my home directory would be safe. On my host, the /tmp/overlay/upper shows me all the changes that happens inside the container's filesystem.

What I really wanted to do was mount that overlay-fs on top of the home directory using something: --filesystem=/tmp/overlay/mount:$HOME, but I do not have the ability to specify the destination mount point

I have used both the above cases with podman. I wanted to see if I can achieve this using flatpak because flatpak provides really good access to the graphics drivers.

[ryanabx]

@GavinNL did you ever get this figured out?

[GavinNL]

@GavinNL did you ever get this figured out?

Hi @ryanabx , no, I did not get this figured out. I think I would require the feature request to be able to do what I wanted. its up to the devs now to determine if this should be added.

[ryanabx]

@GavinNL did you ever get this figured out?

Hi @ryanabx , no, I did not get this figured out. I think I would require the feature request to be able to do what I wanted. its up to the devs now to determine if this should be added.

Understandable. I wish that I liked C in any capacity so I could make some PRs of my own, but I've been spoiled by rust.

[Mannshoch]

I would vote for OverlayFS support in Flatpak

[stellarpower]

My usecase is that not uncommonly I have applications that use some kind of extension/plugin/scripting mechanism. Usually this is in python, and python has enough of a DLL hell without virtual filesystems to start with - although no reason it wouldn't apply to ruby etc, but it increases the frustration, and some apps embed the interpreter inside the binary, others use a separate process, and there are still more weird and confusing options out there that I have encountered before.

So as a user, I open some application, go into settings, install a plugin from an online repository, and this plugin produces a dialogue when I run it complaining it requires extra pip packages.

Without being particularly knowledgeable on flatpak internals, just a user of them, I assume the right way to achieve this technically is to modify the application manifest and add an extension or add more packages ot the build process. That might not be too painful but as this situation has cropped up a few times, it feels overkill every time. And I guess unless there's a clever way to add things on after the main build kinda like how we can build on top of container images, it'd be up to me to assign a custom ID to the application, keep track of upstream changes, and rebuild it. So that's overkill for me.

So I'll choose to be lazy, enter a running flatpak, just install the package manually, and can get on with my day. I can't install to the system directory for whichever of the several bundled python versions that are probably in there as naturally, it's an RO filesystem. The installation completes though, because pip has installed it under ~/.local/lib/python3.x and this is now polluting my host installation, which is obviously a bad thing to do.

For me the simplest solution (read, "hack") would be to make some folder under ~/var/app, one for each application, and mount this over ~/.local/lib/python3.x inside the running flatpak. Thus the packages I needed are clearly visible and separate from the ones bundled by upstream, I can find that folder easily, add some notes, and crucially I can make sure that my host's folder is never mounted inside, as I do in general want my home folder visible, possibly ~/.config, but ~/.local/share is risky in general. I guess most applications will have been packaged well and so will not to touch it, but I do now have a warning at the back of my mind that what I type inside the jail might bleed out so I need to be careful. And with no build changes a standard flatpak update will refresh my system. If python gets bumped or whatever I can simply look at the packages I installed and repeat the process.

So I totally agree with what @smcv has said above - but as a longstanding linux administrator, I guess my view is:

• At times it could have the potential to cause more confusion, not less, when folders are shared with identical paths, as it's sometimes a bit blackbox when most applications are written on the basis of running on the host and then packaged to flatpaks, so it's hard to know if it's going to jump out into the host or not when performing an action
• Thanks to years of unix technical debt, the home folder is unfortunately not as homogeneous as it could be, and potentially mingles things we do and don't want inside (assuming I don't need to explain that to anyone!!)
• Quickly mounting something over a different path might offer a convenient if less-than-ideal way to manage some problems for users prepared to take on the risk themselves.

Although feel free to correct me if there is a much better way to achieve something like this. I generally run things with host filesystem access because as a developer, the files I want to open in an application are rarely under an XDG directory and I want my symlinks all over the place to work.

IDK if there would be enough other motivating usecases to consider it, but I'm guessing seems adding the ability to do this for advanced users but still defaulting to the current behaviour might be possible - some flag like --overlayfor example.

[ElSamhaa]

This feature will make the --filesystem overrides way more useful.

[musjj]

This feature would also be useful for systems with non-standard paths like NixOS/home-manager. To make fonts work, a lot of hacks are currently needed:

https://wiki.nixos.org/wiki/Fonts#Flatpak_applications_can't_find_system_fonts

This includes hacks that compromises privacy, such as making our entire /nix/store directory readable to the sandbox.

If we can just mount our font directory in the path inside the sandbox where most applications expect, it would make all of these hacks completely unnecessary.