[dastx]

One thing I've not understood about flatpak (or their competition for that matter) is why don't these permissions get prompted when they're used? Similar to iOS and Android, ping the user and confirm whether or not they want to give the application this permission. Perhaps even allow for customising the permissions (e.g. when it asks for permission to the homedir, you can override what the homedir would be when prompted).

We are living in a day and age where applications ask for overbroad permissions for many reasons, laziness, privacy invasion, and even legitimate use. Forcing user interaction at worst raises awareness, at best prevents the privacy of individuals from being invaded.

[foobar33333]

I think its more of a one step at a time thing. There is nothing about the design of flatpak which prevents permission popups. The problem is that every desktop program must be rewritten to support this idea and most linux desktop app devs are only vaguely aware of flatpak, let alone ready to start designing specifically for it.

The current strategy seems to be having outsiders packaging all the desktop software in to flatpak while disabling any sandboxing that gets in the way. This brings you to the same state as traditional package managers with little security, but it boosts the flatpak ecosystem and makes it ready for the average person. At that point app devs will be more aware of it and can build their apps to tolerate missing access to things and prompting for access.

[Iolaum]

> This brings you to the same state as traditional package managers with little security

Does it? From the flatpak state you have a far more clear path towards a sandboxed destination.

[lambda_obrien]

Why not just fake stuff? If you give software no file permissions, show it an empty dir. Tell the software you saved it's file but don't, just keep it in an memory overlay just for that program's run. If it wanted the network, give it a dummy net.

[fragileone]

Agreed, the current state is such that many developers either rely on package managers for auto-updates (thus lacks sandboxing anyway) or use Snap (which is usually similarly not sandboxed and you have to put your trust in some proprietary cloud platform to push code to your computer). Just getting devs to support Flatpak is an effort, but once that's done sandboxing can be worked on later.

[epr]

> The problem is that every desktop program must be rewritten to support this idea

No, and expecting that to work is obviously ridiculous. This type of problem needs to be solved in a way which requires no changes at all from developers, or it will almost certainly go nowhere.

[alerighi]

Is not that simple. First you would need a flatpack daemon that manages that permission, that the application could ask for a path (e.g. by writing in a control socket) and the daemon asks the user and mounts that paths inside the container, and then inform the application that the operation is successful. But that would require modifying the application, and not in a trivial way, and it's unacceptable (you need to fork basically every application that you package for flatpack, and the filesystem access could be in various places).

A more acceptable solution would be to intercept all the filesystem related system calls, look if a path is accessible, and if not ask for the permission and either try again the system call and return the result or return to the application E_AGAIN (but is not ideal since not a lot of applications handle that correctly). But this approach would probably require a kernel module, or you can do that with eBPF but obviously you would need CAP_SYS_ADMIN capability so not really possible.

The approach of flatpack is create a container with all the paths that you know the application can access and then jump into the container. A simple solution that even doesn't require a daemon and doesn't require modifying the applications.

[ddtaylor]

> But that would require modifying the application

Technically it can be done using LD_PRELOAD on fopen() and such.

[linmob]

Confirming these settings at first launch is something that mostly annoys users. Remember: Most users just install software via Flatpak because this way they don't have to compile it themselves, deal with a tarball or use an outdated release their distribution ships.

Also, if you want to review or change these settings, you can use Flatseal[0]. Arguably, it should be installed by default.

The problem with flatkill.org is that it leads to users rather downloading a random deb off the internet or an AppImage than using Flatpak, which both have worse security stories.

[0] https://github.com/tchx84/Flatseal

[bayindirh]

If macOS, iOS and Android can get away with one-time permission pop-ups when access is first needed, I'm sure the same model can be applied to Linux.

The annoyance doesn't come from the security, it's from un-refined UX.

[gspr]

> or use an outdated release their distribution ships.

And a good chunk of those people often would be just fine with that "outdated" version.

[harporoeder]

There is a mechanism for this called portals (1) available in flatpak. It gets integrated into the GUI toolkit, and certain applications are not supported. It is useful for things like accessing files from outside the default sandbox.

1. https://docs.flatpak.org/en/latest/portal-api-reference.html

[its-summertime]

specifically, anything that uses the generic GTK/Qt way of accessing files via the file chooser will automagically use the portal

Anything that tweaks on that, most notably Electron, will not use the portal

[varispeed]

In my view these queries about permissions are a bit meaningless. If an app asks me if I want to give it access to my Photos I feel uneasy about that. Which photos? For what? What is it going to do with it? I think the filesystem should be sandboxed and if an app wants to read something I should be able to e.g. give it a directory where it can do anything or I should be able to select a file and the app will have a permission only for that file for a limited time e.g. only to read it once. Also there is no easy way to know what these apps send over network. How do I know they are not downloading all my documents to China?

[Zevis]

If it's anything like on Android, where you just give it blank permission to access your entire storage, it would be useless. There are plenty of programs you might want to use that have no business having access to everything, that you can't or don't want to trust 100%, but it's easier for the developers just to ask for everything (or it's the only option).

The "ask for permission" model is broken.

Everything should be sandboxed without giving the application awareness of being sandboxed. If you want to give additional access to a program, it should be through an external interface only accessible to the user.

[XorNot]

This is where we need to require better programming languages. What we need to be able to prove from code is that when an application is asking for a particular permission, the code paths the data will be used for can be shown not to result in network transmission without going through a trusted transform (if we want to allow it) - i.e. that only SHA512 transforms of that data can end up on the network without gating or something.

[fulafel]

This is probably quite hard to implement without modifying the packaged applications. Needs something like a mechanism of pausing, instead of denying, a system call in the kernel and calling back to userspace, which would then load new policy into the ruleset on the fly and resume execution. Oh and reverse engineer the high level intent of the user / application far enough to present an intelligible question to the potentially nontechnical user.

Maybe some antivirus etc products manage to seemingly do things like this on Windows platforms, but they have generous support from the platform developed over decades, are executing custom 3rd party kernel drivers, are unhindered by opinionated kernel developers blocking the feature due to their distaste for these hacks, and the resulting system is still unsound and rife with stuff like TOCTOU vulnerabilities, and the prompts are not intelligible to nontechnical users.

[KronisLV]

Doesn't this imply that Linux is falling behind somewhat in the area of permissions management? Personally, i think that limiting access to files and such based on users and groups simply isn't enough and instead the user should be prompted (or should be able to configure) which piece of software is allowed to do what (network access, file system access, talking to specific devices) based on their own individual needs.

> Oh and reverse engineer the high level intent of the user / application far enough to present an intelligible question to the potentially nontechnical user.

I don't believe that this is such a big problem, since Android is pretty explicit about this - a camera app asking for access to my contacts will simply get denied and will promptly be uninstalled.

[takluyver]

In some cases it does request permissions when you try to do things. E.g. sandboxed apps without full filesystem access can open & save files through a 'portal' - the system presents the user with an open/save dialog, and the app gets access to the file or folder they select. Things like screen sharing can work similarly - the system asks the user to approve access for the app.

But, as other people have said, this involves new APIs. In the open/save case, the app has to request that the system display a file chooser instead of drawing its own. GTK & Qt can hide this change so apps built on those toolkits benefit automatically. But beyond really self-contained things (like games) most apps that haven't been developed with a sandbox need some adjustment to play nicely within a sandbox. And making changes depends on building a consensus that it's worth doing.

[incrudible]

> One thing I've not understood about flatpak (or their competition for that matter) is why don't these permissions get prompted when they're used?

The POSIX APIs do not have such permissions. You can attempt to put something in between and have lots of stuff break, that's what Apple did. On Linux, there is no such authority.

There are alternatives as well, such as sandboxing all the way up to using a hypervisor for every program, which is arguably what you need to run an untrusted program.

> We are living in a day and age where applications ask for overbroad permissions for many reasons, laziness, privacy invasion, and even legitimate use.

Fair enough, but Flatpaks are mostly open-source software and closed-source software can be monitored far better on a Linux system.

[Blikkentrekker]

Because the system can't be intelligent enough for that.

Say the process wish to write to a particular file; — how far up the directory tree does the system ask for permission?; only that specific path? the home directory?; how can the system know this?

Of course, the other issue is that, say the system be implemented so that the write call blocks until the permission be given, that they will timeout with an error because they have limits on write calls that take that long, and assume there is something else that is wrong like mechanical storage failure, if a simple write call truly take seconds.

[rathboma]

As a desktop app developer this is what I need.

I publish a snap variation and so many edge cases break the security system and make the app unusable.

Home perms? What if the user symlinks something into their home directory? Etc

[gigatexal]

How better or worse is Flatpak than a chmod +x’d AppImage?

[HenryBemis]

Simplistic response: Apple & Google (A&G) don't want people concerned with what's going on under the hood. It is difficult to explain. Also, imagine that you download something, you pay for it, then it asks a question you do not understand (rights 666 or 777? - what the hell? I don't want the devil on my phone!! NO to 666, Yes to 777)(maybe I will win in the casino). And assumming you 'Deny' and the app doesn't work. And you paid $10 for it. You uninstall, reinstall, and 'Allow'.

(Majority of) People barely understand the (privacy/security) impact of giving access to Location, Contacts, Calendar, Phone, SMS. Now think of the more obscure (?) layers of the following pyramid: Hardware, Middleware/Drivers, OS, Applications. (Majority of) People hardly understand Applications. You want to ask them if they can write on X folder? On the OS? Good luck!

Although both A&G can review your code and flag these upfront with some auto-policy-check, I feel that it would send many app creators reeling & pain. Pain for app creators = smaller revenue to A&G.

I assume it's the typical cat & mouse game. A&G may try to reduce/prevent access here but their SDKs will create a new oppotrunity/workaround to get access there. The new "there" access will be abused and someone will find away to do what they were doing in the previous setup. And thus we restart the chase.

It's in the way that people code. Naughty and/or lazy coders will go for the keys to the kingdom, ignoring the security. To avoid misunderstanding the word 'lazy' doesn't mean 'lazy people', but 'lazy/inapprpriate/corner-cutting practices'.

[Closi]

> People hardly understand Applications. You want to ask them if they can write on X folder? On the OS? Good luck!

Well this is how it works in OSX (“Would you like to grant this application permissions to this folder?”), so I guess the answer is “yes - that’s exactly what Apple do”.

[megous]

Reminds me of some bizarro Android permission issues, when I wanted to install a TLS client certificate (pfx) file. I downloaded it via web browser to a phone, opened the certificate management app, and the file was grayed out, no explanation, nada. No way to click on it, no error messages, no confusing permission flags in the file list. I thought the format of the file was wrong, so I tried regenerating it a few times in different formats, wasting an hour or two.

Turns out, you have to copy the file to some folder via adb command line, to make it usable by Android. Copying directly to a uSD card would have probably worked too, but how many people just have a uSD card reader lying around.

But I didn't get a confusing security prompt when downloading from a https:// url, that I might not have understood, so I was better off I guess. /s