Distributors entering Flatpakland [LWN.net]

Distributors entering Flatpakland

Posted Jul 8, 2022 20:44 UTC (Fri) by flussence (guest, #85566)
Parent article: Distributors entering Flatpakland

I like the idea of the declarative permissions sandbox. That's something that can and should be provided in the desktop's app launcher mechanism for everything though, not buried in a specific file format's loader.

to post comments

Distributors entering Flatpakland

Posted Jul 8, 2022 21:05 UTC (Fri) by ejr (subscriber, #51652) [Link] (5 responses)

But how can end-users manage it without at best the Android style permission check? While that appears better than nothing, my view is that people just hit "ok" like all the EULAs.

Distributors entering Flatpakland

Posted Jul 9, 2022 6:52 UTC (Sat) by flussence (guest, #85566) [Link] (3 responses)

Users are already not managing it in any case. Some distros advertise the complete removal of this stuff as a selling point because people don't want security that makes a nuisance of itself or makes easy workflows hard.

Specifically I'm imagining an extension of plain old .desktop files with systemd's existing unit file sandboxing options; reusing the existing knowledge, tooling, specs and documentation of both in a backwards-compatible unintrusive way. A legacy /usr/bin/xdg-open or equivalent launcher would work as usual, newer ones would provide sandboxing in a way that's completely transparent to the user (and the added metadata could be used for a number of other things besides sandboxing - it's the same type of signal browsers interpret HTTPS as).

Moreover it just seems like doing that to begin with would be a more respectful use of everyone's time than yet another format war between what always seems to boil down to IBM vs Canonical vs Luddites. The ever-growing volume of the latter crowd and the fact that these things seem to drag on for years while every corner tries to beat the others into submission are a major missing stair problem.

Distributors entering Flatpakland

Posted Jul 9, 2022 12:00 UTC (Sat) by walters (subscriber, #7396) [Link] (2 responses)

That wouldn't work because it's not just about runtime sandboxing; traditional package systems that install to your root filesystem usually allow any package to put any file anywhere, *and* have the ability to execute arbitrary code as root (%post scripts) at install/upgrade time.

Achieving the goal requires separating the host and application filesytems.

Distributors entering Flatpakland

Posted Jul 10, 2022 8:06 UTC (Sun) by jengelh (subscriber, #33263) [Link] (1 responses)

There was a proposal to use more filetriggers. This would put very common calls like ldconfig, manpage caches and things like that back in the hands of the glibc, man, etc. RPMs, and, as a result, the only %post scripts that should remain are the messy or the nasty ones for which you can then put up big warnings/reject during build/installation/etc.

Distributors entering Flatpakland

Posted Jul 11, 2022 18:40 UTC (Mon) by walters (subscriber, #7396) [Link]

Sure, though that doesn't help at all with the "can put a systemd unit in /etc/systemd/system with an ExecStart=/usr/bin/myapp --inject-root-shell" problem.

flatpak is scoped to install only GUI/desktop applications that should run without any host privileges; you can't use today flatpak to install a (system wide) VPN system or whatever. So by limiting its scope, it is much more secure for its target domain.

Distributors entering Flatpakland

Posted Jul 9, 2022 9:48 UTC (Sat) by NYKevin (subscriber, #129325) [Link]

Users don't want to manage permissions at all. They just want everything to work and for apps to behave "nicely," whatever that means. In other words: This is not a technological problem, it's a regulatory problem.