Zordeer automatic connection request to personal-files

  • name: zordeer
  • description: A launcher for games that run via Wine/Proton.
  • snapcraft: Snap-Zordeer/snapcraft.yaml at main · Kyuyrii/Snap-Zordeer · GitHub
  • upstream: GitHub - Kyuyrii/Zordeer: A launcher for games that run via Wine/Proton.
  • upstream-relation: I am the developer.
  • interfaces:
    • <personal-files>: dot-desktop-files
      • request-type: installation and auto-connection
      • reasoning: It is necessary for Zordeer to create and manage its own .desktop files, and to be able to create the Zordeer category in the applications menu. The command used by default in .desktop files is “zordeer,” which is used to open Zordeer and launch something the user has added; it does not call any app that comes from outside of Snap. The folders used to create the Zordeer category are the same ones that Wine uses to create the Wine category, and are used only for this purpose.
1 Like

This request has been added to the queue for review by the @reviewers team.

Hello @Kyuyrii!

Given the justification provided, I think it makes sense to grant Zordeer permission to read and write certain .dot files. However, it seems a bit broad to allow access to every .dot file. Is there a specific file-naming convention associated with the Zordeer app?

#askForInfo

The .desktop files created by Zordeer are like this: “invocation-lego_batman.desktop”, “invocation-potion_permit.desktop”, “invocation-epic_games.desktop”.

It only creates .desktop files that start with “invocation-”, and only lists and edits its own .desktop files.

Access to the other two folders is only for creating or removing the Zordeer.menu and Zordeer.directory files, which are used to add a category to the application menu, and nothing more.

If I’m not mistaken, it’s not possible to grant access to create, edit, and remove files that have a naming pattern.

I recorded a video so you can understand a little about Zordeer.

In this video, I show Zordeer creating .desktop files in $HOME/.local/share/applications and in the XDG_DESKTOP_DIR folder, I show the contents of the .desktop files, I show that the “Zordeer” category was created in the applications menu, and I show what happens when a user starts a .desktop file that Zordeer created.

https://youtu.be/QuwaFQ1TOYk?si=FWSWc0umJ1WRIvnP

1 Like

Hello again, and thank you for your detailed replies. :slight_smile:

I’ve done some research on this matter and stumbled upon this similar request. Unfortunately, given the discussion there, we cannot proceed with granting the personal-files interface for all the same reasons. (#voteAgainst)

If there is any other way we can help, feel free to reach out!

1 Like

The situation is not equivalent…

I showed what Zordeer does in practice, including the commands used. Everyone can easily see and test what Zordeer does; it’s a very simple app.

As far as I remember, those 3 folders are the only 3 hidden folders it uses. And 2 of them don’t even seem to be usable for anything malicious; from what I’ve seen so far, they only serve to create categories.

In the request you mentioned, .desktop files in the Desktop folder are also treated as a problem, but you can see that what Zordeer creates in the applications folder is exactly the same as what it creates in the Desktop folder, and what it creates in the Desktop folder is not malicious in any way.

I noticed that in the discussion of the cited request, the app in question is being treated as if it were equivalent to game launchers, which they are not.

It was even said after citing the discussion involving UMU: “I think that launchers don’t fit the confinement model particularly well.” This doesn’t make sense, since Steam Snap exists; Steam Snap is proof that this type of launcher can exist in the Snap Store.

I know they take security very seriously, but sometimes it’s excessive precaution. I know I’m not a well-known developer, and consequently it’s harder for people to trust me, but with so many limitations, it’s impossible to deliver a decent user experience.

Snap and Ubuntu users are harmed because of this.

It’s very frustrating to download an app, for example, an emulator, and have to figure out why your gamepad isn’t working.

Or not being able to create shortcuts to your games in a game launcher. This is a common function; .desktop files are seen as shortcuts, not as a potential security problem, because people trust the apps they’re using.

I understand that the $HOME/.local/share/applications folder is not accessible to all apps, but it doesn’t make sense to treat it as something so dangerous to access when the Desktop folder can be accessed without problems and the Desktop folder is used for any type of file, not just .desktop files.

Any app with the “home” plug accesses the Desktop folder, while the $HOME/.local/share/applications folder is accessed by almost no app.

I made the Snap version of Zordeer precisely because I imagine that this is the best way to offer it to users: simple to install because it’s in the Snap Store, secure because it can’t access everything in the system, not needing to add a bunch of 32-bit dependencies to the system, being able to update it easily, and even making it available for older versions of Ubuntu.

1 Like

@Kyuyrii I think this approach can help your app

1 Like

I suppose it’s necessary to explain how Zordeer manages .desktop files.

Games added to Zordeer are called invocations.

Each invocation can have an icon; the icon’s location is defined in the gui_path, always a file within $HOME/AppsFiles/Zordeer/art/gui.

When Zordeer creates .desktop files, it follows a pattern in the Exec= field: it adds the command that calls Zordeer, then --start-invocation, and after that the invocation name in parentheses, for example: snap run zordeer --start-invocation “Lego Batman”

It does this for all selected invocations. If you have 10 invocations, and you’ve selected to create 5 shortcuts in the Desktop folder and 5 in the applications folder, 10 .desktop files will be created/recreated.

In this case, the .desktop files are recreated instead of edited in order to update the icon if it has been changed, and also to remove or add the Zordeer category, instead of making the Zordeer shortcuts appear in 2 categories at the same time.

Also, I forgot to mention that to create or remove the Zordeer category, I need access to the folders $HOME/.config/menus/applications-merged and $HOME/.local/share/desktop-directories. If I understand correctly, I would need to open the file selector at least three times.

In this case, I’m considering the file selector being opened three times because of the first time the user creates the .desktop files in the applications folder, then creates the Zordeer.directory, and then the Zordeer.menu.

Using the file selector, the user would need to confirm twice, once in Zordeer and once in the file selector, every time they create/update/remove .desktop files.

This doesn’t seem so bad because I’m citing Zordeer, which has a .desktop file manager; I don’t remember seeing anything like this in other launchers. So, for example, if Heroic doesn’t have access to the applications folder, it would need to open the file selector every time the user adds or removes shortcuts.

Furthermore, I just did a small test: I copied the Firefox .desktop file into the applications folder and edited the Exec= field to open the Zordeer file, just to test if the XFCE menu would treat the Firefox shortcut as Firefox or Zordeer.

And yes, XFCE did not treat the edited Firefox .desktop file as a different app. In other words, with or without access to the applications folder via a plug, malicious apps can create malicious .desktop files in the applications folder.

There’s simply nothing that can be done.

In short, there’s no way to generate security by preventing access to the applications folder if the way Linux currently works already allows malicious apps to access it.

This way of temporarily granting access to locations is actually a problem.

If it didn’t exist, Snap would be more secure.

Limiting access to the applications folder to non-malicious apps that need to access it only worsens the experience for those developers who aren’t doing anything wrong.

If the applications folder is a danger, what needs to be done is to contact the DE developers so that changes can be made involving the application menus, so that these menus can correctly detect and differentiate .desktop files.

1 Like

Hello, I am in agreement with @yomonokio, this is a -1 (#voteAgainst) from me, aligning with the reasons described in Manual review: appack. From my perspective, launchers and other tools that run arbitrary applications are unfortunately not ideal candidates to be distributed as snaps due to misalignment with confinement principles such as this issue. While I understand requiring users to perform manual configuration steps to set up the snap is certainly less than ideal, doing so ensures that users retain transparency and understanding over the access a snap has to their system.

Voting period has ended. This request is rejected with 0 votes for and 2 votes against.

Zordeer is the best thing happened in a long time in this Wine game launcher field. If only this request could have been granted :confused: for convenient gamepad functionality and so on.

1 Like

The interfaces/plugs are precisely about making apps work on Snap, and the automatic connections are about making users’ lives easier.

The lack of access to certain interfaces should be to prevent malicious apps from doing what the user doesn’t want, rather than preventing safe apps from doing what the user wants.

You might want users to understand what Snap apps access, but it’s not possible at the moment, at least not easily.

The current Snap Store doesn’t have a way to manage plugs, and it doesn’t have a standard for what is automatically connected, precisely because there are automatic connection requests.

So a user can download 2 different video players but only one of them will play the video files that are in /media, /mnt and /run/media, making it much more difficult to understand the access that Snap apps have.

And it becomes even more confusing if the user opens a video by selecting it via the XDG Desktop Portal, they might even think that the app is bugged because of this.

When I first started using Snap apps, I had absolutely no idea what plugs were, and I was extremely confused for several weeks.

I can’t speak for all users, but as a user, I just wanted the apps I downloaded to work correctly.

I didn’t care about security issues precisely because the apps I downloaded were secure, and the Snap versions made them even more secure.

2 Likes