Steam Support already provides access to those .local and .config folders. I don’t know exactly which part of Steam Support does this, but I tested Steam Support on Zordeer and it was able to read and create the .desktop files without needing personal-files.
Creating .desktop files in the menu is a very basic function in game launchers.
If the generated .desktop files are like those in Zordeer, which call the Snap app, it won’t break the sandbox. In Heroic and Zordeer, .desktop files are only created when the user wants them.
For example, a Zordeer .desktop file in the Snap version looks something like this:
[Desktop Entry]
Name=Flynn: Son of Crimson
Exec=snap run zordeer --start-invocation "Flynn: Son of Crimson"
Icon=/home/nufluli/AppsFiles/Zordeer/art/gui/flynn:_son_of_crimson.png
StartupWMClass=zordeer
Categories=Game;
Keywords=gaming;invocation;
Terminal=false
Type=Application
It’ll be the allow all access on files in steam-support, with the personal-files acting as a backup for people who might not have recent snapd interfaces possibly, or just a relic that wasn’t removed.
I’m personally fine with the launcher being able to create .desktop files by default per user expectations, but the breaking of the sandbox is more that the snap, or by extension, any game running in it like cough cough Modern Warefare 2 (et al) cough cough RCE cough cough would, could freely write exec=bash -c 'rm $HOME -rf' or worse, and even be able to call that desktop file itself with xdg-open by throwing an X-Mime in there for good measure. That’s why to me it makes sense to have that split between two interfaces, being able to create those files is important for your use case but it should ideally be each interface is minimally scoped when we’ve an easy solution to achieve the same thing anyway, you’d just be given autoconnection for personal-files on top
It might not be needed anymore, but it was certainly intended to be there.
If there’s something truly malicious, just accessing the $HOME folder will be enough to create problematic .desktop files, since the Desktop folder is located within $HOME.
So ideally, apps should be prevented from accessing the $HOME folder, but this would make them much more difficult to use, as accessing the $HOME folder is the minimum users expect.
Furthermore, some users will place files on secondary HDDs/SSDs using the removable-media plug, granting access to even more files.
I wouldn’t have expected that .desktop files in $HOME/Desktop would work, but if they do, it’s probably worth a discussion elsewhere
The home interface allows for that though, since these are Windows apps, they’re already being tricked on the layout of the filesystem anyway, so unrestricted $SNAP_REAL_HOME access is technically entirely optional from an application POV. Users could probably manually disconnect the interface or use the prompting-client to do the same and still have usable games that can still write save files, because the Windows %USERPROFILE% will go through several layers of containers but ultimately end up at $HOME/snap/heroic/current/ (it’s $HOME). Combined with the personal-files split, this eliminates access to $SNAP_REAL_HOME almost entirely and would actually block the concerns around those files effectively.
Similarly that’s an argument for the access in umu-support to /mnt/ and /media to be removed and replaced with an autoconnection to removable-media instead, the thing is, your comments suggest that not having at least read access causes Umu to break, so it’s not optional (unless patched I guess). And read only in your interface is more restricted than removable-media itself which is read/write, meaning to support that use case you’d need both anyway, but that particular folder and implications around it balance slightly differently to me than $HOME and the .desktop folders - yes you could see the files on my external drives, but that’s still better than being able to also change them.
I ran a test here, I tried to run an .exe file that’s on one of my hard drives, but without the removable-media plug connected, it gave several access denied errors, and then it wasn’t possible to start the installer. I tested another .exe file, and it didn’t even open an error window.
The umu-support only has access to the /media, /mnt, and /run/media folders, but it doesn’t have access to the subfolders, which is where the users’ files are located.
I think that’s ideal in this instance, I hadn’t clocked that it doesn’t actually give access to the subfolders, so that’s great overall from your interfaces POV. It’s only really leaking that you might have external drives, not even what’s in them. Since removable-media exists and would be non-controversial for things like Heroic, I don’t think how it is causes any real concerns, since you could just ask for that down the line, or manually connecting it is always an option.
