LWN: Comments on "Flatpak 1.0 released"

Application isolation

chipaca — Sat, 25 Aug 2018 03:19:28 +0000

Snap packages are the evolution of click packages, which were what the Ubuntu Phone used. FWIW.

Application isolation

chipaca — Sat, 25 Aug 2018 03:16:38 +0000

Funny how memory works.

The way I remember it, Canonical's work around isolated apps was out and in use years before flatpak was a thing.
We called it 'click' then, and used it on the Ubuntu Phone. This work predates even xdg-app by two or three years.
Then we built a 2.0 of that, and called it snap, and released _that_ in the 15.04 timeframe.
Even that was before flatpak.

Application isolation

flussence — Thu, 23 Aug 2018 23:20:48 +0000

I'll add that 0install existed in 2005, so arguing which of these was first is a moot point. They're both NIH controlled by warring factions.

Application isolation

flussence — Thu, 23 Aug 2018 23:02:48 +0000

Ironically, one of the things I've heard Flatpak is used for is running Windows games (usually pirated) with a bundled Wine.

Application isolation

liw — Thu, 23 Aug 2018 09:52:40 +0000

Let's not rely on memories. The memory subsystem of human brains is even less reliable than floppies.

Wikipedia reports Snappy as being first release in December, 2014, which means it will have been in development for some time before that. (link)

Flapak's history page reports its origins as starting with Glick in 2007, with iterative evolution to what we now know as Flatpak via Glick2 and xdg-app.

Overall, it seems to me that Flatpak and Snappy have developed in parallel, learning from each other, in the way free software often does. There doesn't seem to be a clear answer to which one came first. I don't think it matters, either.

Application isolation

mgedmin — Thu, 23 Aug 2018 09:31:23 +0000

I remember it the other way around:

- Snap was first, but only worked on Ubuntu
- xdg-app (old name of Flatpak) was announced as a cross-distro solution
- Canonical rushed ports of Snap to other distros, dropping the sandboxing in the name of expediency

I wasn't paying attention so I cannot comment on the current state of Snap on non-Ubuntu distros.

Application isolation

astian — Wed, 22 Aug 2018 19:57:46 +0000

Thanks for the summary.

Application isolation - PA

zlynx — Wed, 22 Aug 2018 17:41:49 +0000

How exactly would that help? If the kernel audio interfaces allowed recording you'd be in the same fix because the kernel ABI cannot be changed.

In the past before ALSA with OSS audio there were horrible library hacks to intercept open(), read(), write(), ioctl() calls to audio devices so that kernel behavior could be modified. There are *reasons* why things are now in userspace.

Application isolation - PA

kloczek — Wed, 22 Aug 2018 14:02:23 +0000

So many years people have been telling to stop doing those nasty things with alsa/pulseaudio in user space and move all to kernel space .. no one listens.

Application isolation - PA

darwish — Wed, 22 Aug 2018 10:05:51 +0000

> for example, access to PulseAudio is currently a binary yes/no choice per app, and there's no way to say "this app can play sounds, but can't use PulseAudio's shared-memory transport, and can't record".

This was initially going to be solved by adding Access Control support to PulseAudio, along with lots of PA code re-design to guarantee real isolation:

https://www.freedesktop.org/wiki/Software/PulseAudio/Docu...

https://lists.freedesktop.org/archives/pulseaudio-discuss...

AFAIK Fedora merged these Access Control patches on their own, but as seen above they are definitely not enough. The tide now is go with PipeWire since it's careful to solve this problem correctly from the start.

Application isolation

smcv — Tue, 21 Aug 2018 22:43:49 +0000

The sandbox itself is as good as any other unprivileged container based on namespaces: the sandboxed app has access to the kernel's (significant) attack surface, but with strict permissions it can't do much to interact with the rest of the system. On some kernel configurations (notably Debian and RHEL), bubblewrap normally needs to be setuid; on others (notably Fedora and Ubuntu), it can be unprivileged. (The difference is because by default Debian and RHEL kernels don't let unprivileged users create their own user namespaces, whereas Fedora and Ubuntu kernels do.)

The fine print is that to let an app do useful things (draw a window, play sounds, contact network services, load and save per-user preferences, etc.) it needs to have some permissions (gaps in the sandbox boundary), and at the moment many of those permissions are more coarse-grained than you might hope: for example, access to PulseAudio is currently a binary yes/no choice per app, and there's no way to say "this app can play sounds, but can't use PulseAudio's shared-memory transport, and can't record". This should get better with continued development, partly in Flatpak itself and partly in other projects adjacent to it.

Trolling

renox — Tue, 21 Aug 2018 21:04:52 +0000

Please refrain to put such low quality comment on LWN, reread the guidelines: "Please try to be polite, respectful, and informative".

Application isolation

atai — Tue, 21 Aug 2018 17:29:22 +0000

the scope of your interests is very narrow

Application isolation

drag — Tue, 21 Aug 2018 16:11:42 +0000

I think your memory isn't very good. Seems your recollection of events is little more then a series of strawmen and half remembered assumptions.

Regardless getting applications sandboxed is just the first step to finally achieving some level of security on the desktop. Going against the nearly 50 year long trend of 'all your applications run with the same rights as you' is a extremely tough task and requires changing and improving a lot of moving parts. Being able to control application access to your system through namespaces and file system images is just one part of the puzzle. (Getting rid of X is another. Layering LSM/Selinux/Apparmor over that is another, etc etc)

Plus Linux desktops desperately needs a universal package management system for applications. Having each and ever Linux distribution package the entire planet of software independently for each of their releases/branches is something that scales extremely poorly and leaves huge number of gaps. The internet has created a extremely long tail of software that just will never, ever, be supported by any distribution repositories yet application developers still want to write them and users will still want to use them. And it has absolutely nothing to do with 'doing it windows style'.

You can see this as evidenced by the fact that no Linux distribution ever really was able to make it easy to develop and redistribute video games, games engines, games related software/libraries/dependencies. There was huge number of attempts and distributions tried to package as much open source software as possible, but whatever they packaged became obsolete or old in short order. Users are loath to use a version of a game from 6 months ago if everybody else is playing the latest versions on public servers. As it stands right now if you want to install open source games or games built using open source software with proprietary content... the best way to do it is via Steam. Being at the mercy of a major proprietary corporation whose Linux support is effectively little more then a experiment at trying to manipulate Microsoft into behaving better isn't a good place to be.

Hopefully stuff like Flatpak can help reverse this trend.

Application isolation

tux3 — Tue, 21 Aug 2018 14:48:19 +0000

My understanding is that they've been using Bubblewrap as a sandbox (https://github.com/projectatomic/bubblewrap), which is a sort of homemade lightweight user namespaces implemented with a setuid helper.

As far as I can tell, as of today their sandbox seems perfectly functional, but if there's some fine print hidden somewhere I'd love to take a look at it!

Here's their wiki that I've only quickly glossed over: https://github.com/flatpak/flatpak/wiki/Sandbox

Application isolation

astian — Tue, 21 Aug 2018 12:09:05 +0000

I remember during the early hype days of Flatpack and containers, the former was hailed as a secure(r) mechanism for 'running arbitrary blobs off the Internet' (windows style), because each Flatpack-packaged application was supposed to run confined into a container which was largely isolated from the rest of the system. Later when Canonical released (or announced, can't remember) Snappy, the people behind Flatpack rushed to a sort of 'preliminary' release. In order to make the deadline, several features had to be scrapped^Wpostponed, one of them being isolation, the only one I was really interested in.

I wonder if/how the situation has changed.