Gnome "Software" flags

Gnome “Software” flags my Flatpak with a big red scary “Unsafe” flag, as it can allegedly “Read/Write all your data”. That is untrue, as it can’t touch the root directory or other disks, which is borne out by clicking for more information. “Software” states: “Home/Folder Read/Write access. Can read and write all data in your home directory.” - not root. It has " - --filesystem=home".
Potential users might be put off installing it because of the flag - but would be unusable without access to their home directory. Being able to write to one’s home directory seems perfectly reasonable to me. Wouldn’t a milder warning be more appropriate? I see that Gnome apps like “Files” are “Approved by your distribution” - so no scary flags, how is that achieved?

Might you be using Fedora? Fedora has a filtered flatpak repository and perhaps that is why Files is flagged as approved by your distribution for you. I’m on Arch Linux and the Files flatpak is marked as unsafe because it has full filesystem access.

1 Like

I’ve just been told that it’s nothing to do with Flatpak and to discuss it with Gnome - which is why I posted here. I assumed Gnome had approved their own software :slight_smile:
“Fedora has a filtered Flatpak repository” I’m on Fedora, so I’ll try them.

I just read that changes are coming for Fedora 38: Changes/UnfilteredFlathub - Fedora Project Wiki. The section I linked to provides some more info about how it currently works. Fedora has its own flatpak repository (flatpaks built from the Fedora archive) and an allowlist (filter) for Flathub. From which does the Files flatpak come?

1 Like

It’s not a Flatpak, the only option offered is an RPM.

Ah, apples and oranges. I think these warnings are only in place for flatpaks. Same as when you go to Settings > Applications, flatpaks expose more detail and options than native packages do.

Getting back to that, the unsafe flag is shown on almost all flatpaks for me. Because most apps aren’t perfectly sandboxed and as you wrote there’s a good reason for that with most apps.

I don’t know if it is off putting to users. If the user assumes because an app is sandboxed it won’t be able to touch their ~/Documents/BigSecretProject/ files … hence the label I think. The details explain why it is unsafe and if the user trusts the app with their home directory they are at least informed but can ignore this. Or the user can make the sandbox more restrictive for the app.

1 Like

I’ve posted a thread on Fedora, suggesting that it is too harsh a warning and asking how an app gets “Approval.”

In the meantime I’ll assume that potential users’ have the common sense to ignore the warning. I’d rather do that than irritate 99% of them by restricting their access to one directory - and even then get a mild warning.

asking how an app gets “Approval.”

There is no whitelist of apps for which full home access is considered safe.

If possible you should use the FileChooser portal to only get access to the necessary files (and which the user has explicitly consented to). Otherwise you’ll have to live with the warning.

1 Like

it’s not that your app needs to restrict itself to one directory, it’s that the user has to be in the loop. by using a portal api, the user picks what files they want your app to see using a file chooser that runs outside the sandbox. it’s about putting the control in the hands of the users

2 Likes

Do you mean that this runs as part of the installation process and because the user is explicitly asked during installation the scary red flag doesn’t appear?

Your home directory is where you store all your data, so warning that the application can access all your data is very reasonable. The app is effectively disabling the flatpak sandbox and it needs to not do that if it wants to avoid the scary warning. In 2023 this is no longer acceptable, but many apps still do so anyway. My opinion is that these warnings are insufficient and applications that subvert the sandbox should be delisted from flathub and/or hidden in GNOME Software, but the flatpak ecosystem may not be ready for this quite yet, so for now displaying the apps as unsafe is a way to turn up the heat and encourage applications to stop subverting the sandbox.

This user interface really is terrible because RPM-based applications are equally dangerous, yet they are displayed as safer than unsandboxed flatpaks, which is outrageous. They should all be marked as dangerous.

No? The user is never explicitly asked to approve anything. If the user does not notice GNOME Software warning that the application is unsandboxed, then the user has no idea the app is dangerous.

No, you can set the app permissions to not allow full access to the home directory and instead at runtime let the user choose which file to open with file chooser portal: Desktop Integration - Flatpak documentation

Doing it this way doesn’t mark the app as unsafe. For example Upscaler uses that and is marked as safe in Software. (Upscaler can upscale images; it has a button for the user to choose which image to open and another to choose where to save the result.)

2 Likes

My app uses GTK4 and does what’s recommended:

Portal support in GTK

GTK will transparently use portals for some functionality when it detects that it is being used inside a Flatpak sandbox. Here are some hints for what GTK applications should do to benefit from this.

  • Use GtkFileChooserNative

Which allows the user to read files - can I assume that would still work if I removed the " - --filesystem=home"? It wouldn’t work for writing files though, the app processes the (approved) input files to create output files without being asked. Having to use a file chooser would be very irritating.

You mention “an allowlist (filter) for Flathub” in post-4, but I assume that means “show the app in Software” rather than “allow it access to the home directory without the need to show a red flag”.

The only way I can see of making this work would be to give a description of what the app does during installation, then ask for approval. Since that’s not been mentioned anywhere, I’ll just have to put up with the red flag.

Upscaler works fine without " --filesystem=home". But I don’t know if you need to do anything different in the code for opening the file the user selects.

IMHO the red flag seems like “crying wolf” to me, an amber flag might be more appropriate. If users see a red flag for access to their home directory, which is a reasonable thing, they may ignore it in future. On one of those occasions it could be doing something really bad. That’s a matter for the distribution to decide though I suppose.

an amber flag might be more appropriate.

Giving an app access to your password store, your browser history, your tax declaration, your company’s NDA documents etc? For virtually everyone, nowadays access to the home directory is much more sensitive than (read-only) access to root.

1 Like

You can write to the file that the user has selected in the file chooser. If you need to write a file that the user did not select, the best you can do currently is open a file chooser in directory selection mode to get access to the directory that the user selects (but yes, something better is needed).

Home directory access is the god permission. If this is reasonable, then there’s no point in having any other permissions at all. We might as well all give up on making Linux safer for users.

1 Like

The only way I can see of making this work would be to give a description of what the app does during installation, then ask for approval. Since that’s not been mentioned anywhere, I’ll just have to put up with the red flag.

I don’t really see how giving a sandboxed app the ability to read arbitrary files in the home directory could ever work. I mean, that gives the app the ability to impersonate the user using their browser cookies etc. it totally defeats the sandbox.

IIRC, the portal API lets the user pick a directory instead of a file. Would that work for your use case?

EDIT: Actually, looking, I don’t think that will work. It just gives you all the files in the directory.
EDIT2: I take that back I was looking at a stale check out. I think it may work after all.

There are many good reasons I’m using a Flatpak, sandboxing isn’t one of them. Do RPM packages get flags?

Sure that’s fine, but one of the core features of flatpak is that it helps provide a sandboxing story. You’re welcome to take it or leave it of course. it’s an optional feature.

GNOME Software let’s users know, though, which apps have the ability to look indiscriminately at their files without their knowledge or consent. I’m not saying your app is doing anything nefarious or destructive, but there’s value-add for a user to know that running an app as a flatpak won’t lead to browser cookies getting sniffed, or bugs accidentally destroying $HOME. That’s the motivation behind the GNOME Software design.

Out of curiosity, have you tried running your flatpak without - --filesystem=home ? It may just work. If it does that’s a win-win for everyone.

1 Like