Hacker News Reader

Comment by minimeow | Hacker News Reader

My trust in Flatpak diminished after installing the book reader Calibre and finding that despite the sandboxing Calibre was given blanket access to my drive. Apparently a quirk of the developer behind Calibre insisting upon it. No warnings or communication of the exception were given. All trust I had in Flatpak was eroded from that moment on. Curious about the podman options or similar. Having desktop apps in a container with selective access to system resources seems like it would be more secure and configurable if configured correctly. Flatpak as it stands seems to be a legacy solution to what should be a container and namespacing solution.

View on HN

Don't know how you installed it, but required permissions are usually shown and warned about. The CLI could be clearer, though, but shows that host filesystem access is granted to calibre when it prompts to install

Permissions being granted implicitly is awful for security.

During installation they're _mentioned_ but the you can't pick which permissions to grant. If the developer requested it, its granted by default.

There are third party tools to tinker with permissions, but even those tools follow a "implicit grant first, revoke later" model, mostly because of how Flatpak implicitly grants permissions.

It's explicit in the sense that you choose to grant those permissions, but I get what you mean. Android apps also used to be more like that but nowadays you can have more control when to grant access to what. Flatpak apps can also explicitly request access through portals, but many apps probably haven't put the effort to properly use the sandboxing features and instead try to request excessive permissions beforehand.

> No warnings or communication of the exception were given. All trust I had in Flatpak was eroded from that moment on

This is just wrong. Clients like the flathub website or gnome software show the risk posed by wide ranging access to local files, but Flatpak has to support legacy applications that don't use portals yet and thus they can't block applications having those permissions

https://flathub.org/en-GB/apps/com.calibre_ebook.calibre

> calibre is potentially unsafe

> Full file system read/write access

> Can read and write all data on the file system

The flathub website warnings are good, but some warnings in the CLI would be nice as well.

What it looks like in the CLI (depending on the host):

  com.calibre_ebook.calibre permissions:
    ipc                         network      fallback-x11         pulseaudio
    wayland                     devices      file access [1]      dbus access [2]
    system dbus access [3]

    [1] host, xdg-config/kdeglobals:ro, xdg-data/Trash, xdg-run/speech-dispatcher:ro

I think it is easy to skim over "host" there

> Flatpak has to support legacy applications that don't use portals yet

That was the wrong architectural tradeoff, IMO.

Had similar concerns about the default sandboxing, so had to use `--sandbox` with every app and then carefully engineer the permissions so the apps would actually work.

After reading about potential future problems with Flatpak on my distro, I decided to experiment more with Bubblewrap. It turned out to be surprisingly easy to build a minimal container manager around it (here comes the shameless self-plug): https://github.com/pakstak/pakstak

Although for desktop apps, it is not as easy as just packing an app into an OCI container and expecting it to work. Since you are basically building on top of the kernel, which brings true portability between distros, you have to provide the userspace part of the drivers, and this layer depends on your hardware. Overlaying an app container on top of a "driver container" can help with this though.

That’s what the kasmweb images on dockerhub are - desktop apps containerised

Reply on news.ycombinator.com