Reevaluate permission for external disks (huge security risk for backups)

[gechoto]

UPDATE: see #1531 (comment) & #1531 (comment)

---

The steam flatpak added full read/write permission for secondary and external disks.

Having a steam library on external disks already worked before (without this permission).
I just tested it again by removing all filesystem permission and it still works.

I wonder what this is supposed to fix?
Can you explain in which cases this is really needed?

However it comes with a big downside:

It is somewhat common to use external disks for stuff like backups. Many users copy all their important stuff to backup media (including ssh keys and so on).

Now Steam sadly sometimes hosts malware.

This malware now has access to SSH keys and other private data.
It can infect other files with malware and when users try to run the programs from their backup drive it can easily infect the rest of the system.

This is a huge risk and helps malware a lot.

Please reevaluate or explain why this is really needed.

[gechoto]

tagging @yakushabb since you suggested these in #1522 (comment)

did you test it? are those permission necessary in your testing?
if so, what is your system?

in my testing it already worked without those permissions

I can add a steam library directory on an external disk and Steam will only have access to that one specific directory. This already was a great solution and much more secure.

[gechoto]

cc @CreamyArch since you created a similar issue and I think it is very sad and unprofessional to just lock an issue without allowing for discussion

[yakushabb]

Do you have any immutable systems?

@exedyos reported the issue via the following issue: #1522

[gechoto]

Do you have any immutable systems?

Sadly I don't. Do you? Can anyone test on an immutable one?

I want to add the info that even if it does not work on immutable systems, this would be a flatpak / portals or distribution level bug and needs to fixed there, not by adding full permission for malware to steal and infect backups and so on.

Also if this turns out to be an issue on immutable systems a lot more flatpaks would have issues (all which use portals for scoped filesystem access) so I wonder if this is something specific to the system the reporter used in #1522

let's investigate...

@exedyos which system / os are you using?

[gechoto]

UPDATE:
sorry I missed something while testing
what was tested:

• adding a steam library on external disks works
• playing games from external disks works
• moving games in steam to this external library works

the only thing I didn't test was downloading new games directly to the external disk/library.
this sadly fails with an "DISK WRITE ERROR" in steam

in the terminal it looks like this:
flock /run/user/xxx/doc/xxx/Steam-Lib/steamapps/downloading/state_xxx_xxx.patch LOCK_SH failed. errno = 38

@exedyos can you confirm that this is the exact error you saw while reporting your issue?

btw full read, write and execute operations work with the external library mounted by the portal. the only thing that fails is steams file lock while downloading a new game.
I wonder if this can be fixed.
Maybe this is a bug in the portal code?

Please do not close (and especially not lock) this issue yet. We should further investigate to see which part exactly fails since this seems like a bug. And I still don't think giving malware an easy time is a great workaround for a bug.

Also remember that bugs like ValveSoftware/steam-for-linux#3671 exist and something similar can come back in the future.
Full read/write access to external disks is too much of a risk imo.
Let's focus on actually fixing the flock bug instead.

[gechoto]

Seems that flock is not implemented in the xdg-desktop-portal yet. There was an attempt: flatpak/xdg-desktop-portal#1353

I asked over there to see what the state of this is.

I hope very much this can be fixed/implemented soon to avoid such workarounds which impose huge risks like it happened here.

EDIT: created a new issue to track progress, now we have to wait for this:
flatpak/xdg-desktop-portal#1951

---

Again I'm sorry for the partially incorrect info in the initial post because I used an existing library for testing.
Still, for the time being I think it is better to have a little inconvenience (adding permission to a specific directly on external disks with Flatseal) instead of opening users up for huge problems.
Again, it is common to have backups on external disks so adding full permission for external disks is somewhat similar to giving Steam games and malware full access to the users home directory. At this point there is pretty much no point in sandboxing anymore.

[bbhtt]

I recommend that people at least search for the multiple issues opened over the several years for having this permissions including the workaround being listed in metainfo and wiki before making these issues with sensationalised, absurdist titles and incomplete information in them.

If you are unable to search and keep creating duplicates or incomplete issues, I will have to start blocking people.

#909
#1301
#1319
#1511
#1522

Again I'm sorry for the partially incorrect info in the initial post because I used an existing library for testing.

So please stop making incomplete issues. I'm aware some things work and some don't.

Still, for the time being I think it is better to have a little inconvenience (adding permission to a specific directly on external disks with Flatseal) instead of opening users up for huge problems.

It may be better for you but the average non-technical users will not know or understand any of this. If you care about it you can disable the new permissions using flatpak override, conversely.

And if you are afraid of malware in steam, you should stop using it in the first place. It has network access, so that's already a bigger risk of a malware stealing data and sending it over the internet.