EternalModManager is a mod manager for DOOM Eternal which assists in handling mods and the mod injector settings, and makes it easier to load mods into the game on Linux systems.
I’m requesting classic confinement because:
The snap needs to interact with various files in the DOOM Eternal game directory, which can be installed almost anywhere in the user’s system (since Steam libraries/WINE bottles can be on various locations accross the drive), and it’s not possible to know where will the user have the game installed.
The electron app uses a shell script to inject the mods after you are done with installing and configuring your mods, which requires access to various files inside the game folder, and has errors with strict mode.
Also, there are standard locations for game related files and also for the libraries you are mentioning so you should be able to plug some interfaces like home, personal-files and even system-files if needed and keep EternalModManager under strict confinement.
@emitorino I have looked into the provided interfaces and after some testing I haven’t found any interface that can guarantee access to all possible game directories. What would you suggest for this situation?
@emitorino I think you are allowed to make a steam library folder on any folder owned by the user, making it possible to have a game directory almost everywhere after using the chown command. As for Wine/Lutris prefixes, I’m not sure which directories are allowed.
What about someone using the chown command to install a game in a different directory (like in this StackExchange question)? That’s what worries me.
Worst case scenario I’ll use both the home and removable-media interfaces and hope no one puts their game folder in a weird location, unless there is a better method?
Electron 14 (currently in pre-release) might be able to help you, if you use the graphical file picker to select the directory, you might be able to access directories outside the sandboxed environment due to this commit that enables XDG portal support
It’s probably worth trying the Electron 14 beta and seeing if it can help you here. You might need to ensure the environment variable GTK_USE_PORTAL is set to 1
From your apps perspective, any file/directory outside the sandbox would end up in $XDG_RUNTIME_DIR/docs which it should be able to access fine, and any changes in that directory effect the original.
No, the change above runs the file picker in an external process outside of the sandbox, so it can see the full system. This doesn’t violate the sandboxing principles because the external file picker is trusted, and if the user gives consent to files that are restricted to the snap making the request, the mount magic will open a minimally scoped hole to the exact files/directories selected and not the rest of the system.
While the change above is implemented via GTK3 (and you’d likely need to ensure that your snap then ships with GTK3), that’s an implementation detail about Electrons handling of it. The process that actually handles the request might even end up showing a KDE/Qt filepicker if the users are on a KDE system.
(eternalmodmanager:52054): Gtk-WARNING **: 00:45:50.970: GTK_FILE_CHOOSER_ACTION_SELECT_FOLDER is not supported by GtkFileChooserNativePortal because portal is too old
Unfortunately it turns out that the ability to open arbitrary directories is a feature of xdg-desktop-portal >= 1.8, which is a new package. Ubuntu 21.04, Debian 11, Fedora 34 all have it, but 20.04 doesn’t. If the above was run on Ubuntu 21.04, I’d be reasonably confident it’d work.
Opening arbitrary singular files however works with much older portals, but this unfortunately isn’t helpful here.
If you weren’t getting the above error and it didn’t work, I’d assume it’s due to the snap environment not being quite right. I’ve forked your repo and added a snapcraft.yaml file that means the snapcraft tool should work, which is the usual way of building snaps and avoids Electron Builder, it’d also enable you to make use of Snapcrafts automatic builds if wanted too. Hopefully if you clone that branch, bump it up to Electron 14, and try do it graphically on a compatible system it’d work for you.
However as far as sytems go that don’t have the newer package, I think your current situation of relying on the home and removable-media interfaces might be the only solution considering current policies.
@powerball253 you still have the option of staying under strict confinement and plug the interfaces we suggested. I see you have not uploaded a new revision applying such changes, are you willing to do so?
I will probably use the home and removable-media interfaces, however the second one doesn’t allow auto-connection as per the documentation (and yet again, my app isnt in the list of exceptions that may be granted auto-connect), do you think it’s worth it to try and request it?
