[Feature request]: complete host system access

[hsitter]

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

We could really benefit from a more sledge-hammer approach to getting out of the sandbox.

Background

At KDE we have some apps that want access to all files on the system, either to invoke them or to read them. I've done my best to rejigger them behind flatpak-spawn but honestly it's awkward to program, an additional source of bugs when you forget it, and sometimes simply not practical.

Notable mentions include

disk usage visualizer https://apps.kde.org/filelight/

We have gone to great lengths to give this tool incredibly high performance, after all, if you scan terrabytes of data every little bit adds up. The basic use case is that the user selects any directory on his system and filelight traverses it. This simply isn't doable right now outside home. We can add host/host-os but then we still don't have access to /usr to /var etc.. What we need is a raw access to the entire directory tree.

terminal https://apps.kde.org/konsole/

For the most part I've gotten away with flatpak-spawn here, but honestly it's not enough. A particular problem I remember is that process detection is entirely broken with the flatpak. Konsole does some magic with the /proc of forked processes to figure out what the working directory is, what their status and cmdline is etc. This simply isn't doable right now outside flatpak-spawning a million cat commands.

IDE/editor https://apps.kde.org/kate/

Again careful flatpak-spawn usage solved most of the problems here but the remaining 10% cause death by a thousand papercuts. It embeds konsole so the same problem plaguing konsole apply here too.

File manager https://apps.kde.org/dolphin/

Pretty much in the same boat as filelight. Not having complete directory access is getting in the way of many advanced use cases. Plus it embeds konsole, so same problem as above again.

A way out

Those are just some of the things I have personally worked on, I'm sure there are other problematic apps.

Since most of the problems are to do with file access, a trivial solution might be a special filesystem access that binds the entire system root under /var/system inside the sandbox. This would allow most of the aforementioned use cases to get through to the host. While technically still keeping the sandbox, albeit a very moot sandbox.

Another option might be turn this around and move the flatpak /usr out of the way. For developer tools like an IDE, terminal or file manager it's not really practical to be inside a sandbox, still it is very desirable to have a portable means of distributing them. Consider the poor developers in corporate environments stuck on some LTS distribution but wanting to use the latest in IDE technology. Currently they have to build stuff natively, if the ancient base libraries even allow for it. For instance, something like snapd's classic mode that the user has to explicitly opt into, where the app runs basically on an unchanged / except for /app and /runtime. Apps have to explicitly pull in assets via LD_LIBRARY_PATH and friends to work this way - Not pretty but it works well enough in practice.

I appreciate that this would be a huge departure from the sandbox story, but hope it's worth considering at least :)

[JakobDev]

on an unchanged / except for /app and /runtime

The problem here is, that the Runtime lives not in /runtime. The Runtime provides a lot of directories in / such as /usr or /lib, so you can't simply mount the existing host directories.

[hfiguiere]

$ man flatpak-metadata
[...]
       filesystems (list)
           List of filesystem subsets to make available to the application. Possible values:
[...]
           host-os
               The host operating system's libraries, executables and static data from /usr and the related directories /bin, /lib,
               /lib32, /lib64, /sbin. Additionally, this keyword provides access to a subset of /etc that is associated with
               packaged libraries and executables, even if the host-etc keyword was not used: /etc/ld.so.cache, (used by the
               dynamic linker) and /etc/alternatives (on operating systems that use it, such as Debian).

               To avoid conflicting with the Flatpak runtime, these are mounted in the sandbox at /run/host/usr,
               /run/host/etc/ld.so.cache and so on.

               Available since 1.7.
[...]

(there are others values too)

[bbhtt]

This is a dupe of https://github.com/flatpak/flatpak/issues/5644 with the same request

[hsitter]

on an unchanged / except for /app and /runtime

The problem here is, that the Runtime lives not in /runtime. The Runtime provides a lot of directories in / such as /usr or /lib, so you can't simply mount the existing host directories.

Hubert's comment seems to suggest it is possible, at least under /run. I probably didn't make myself very clear with my proposals:

One possible approach is to bind the entire root into some special directory (I used /var/system as example, but it could be /run/host-complete or something) so from the application side we just need to bend its understanding of root from / to /run/host-complete and things start working.

Unfortunately none of the current access modes seem to give us access to a "pristine" version of the host system, so while filesystems=host-os goes in the right direction it's not yet quite sufficient for the use cases we have.

The other would be a completely new operation mode with the sandbox turned inside out such that all flatpak artifacts are inside /app and /runtime while the rest of the tree is that of the host. Much more work of course but I thought I should bring it up since we've had good experience with that on the snap side.

[nanonyme]

Yeah, this isn't really feasible

[bjoli]

So: I am definitely way out of my pay grade here, but I made the flathub emacs version work A LOT better by advicing the commands emacs uses to run external commands: if the executable existed it ran them without modification, otherwise it piped it through flatpak-spawn --host. It still runs into errors when trying to execute shell scripts (because I didn't also patch sh), but it makes all of my emacs usage just fine (geiser and slime).

Maybe something similar could find it's way into applications that can talk to org.freedesktop.Flatpak. It is not a pretty solution, but it makes apps that needs access to host executables in $PATH run without issue. It would not be enough for the KDE needs above, but it would make emacs a lot more usable.