[Feature Request] Request access to file at known path

[tpotancok]

I'm working on a new method to the Bottles URI handler that lets it run Windows executables anywhere on the system, not just programs added to the list before. The executable path gets passed as part of the URI. Right now the only way to request access to the file is with the FileChooser portal. This means apps have to handle users who pick the wrong file, and pre-selecting the right one doesn't work if access to the containing directory wasn't granted before.

We can fix this by adding new method on the Documents portal that lets the app request permissions for a file at a specific path. The user would see a dialog that shows the path and permissions and lets them grant or deny access. Granting access adds the file to the app's document store. Access is automatically granted if the app already has the requested permissions and automatically denied if the filename doesn't point to a valid file. The method signature can be:

RequestPermissions (IN  ay filename,
                    IN  as permissions,
                    OUT s doc_id);

doc_id is the document ID if access was granted or '' if it was denied. We could also let the user grant some of the requested permissions and deny others, but I feel like that would just be extra complexity and devs can work around the limitation if necessary.

[Mikenux]

Hello,

What do you want here, because I don't understand...

The user opens an exe file on their system, but it is not the correct one. How do you request the correct one with a file path you don't know?

Also, when I see your MR description on the Bottles github, you say it would allow other flatpak apps to open the executable with Bottles... But don't those launchers manage their own wine versions? Or do you want to be able to use the wine version of Bottles and run the executable with the launcher arguments (not Bottles)?

[tpotancok]

You do know the file path if the user passed it indirectly, like with a URI parameter or a file the flatpak already has access to. The only workaround other than FileChooser is if some other app grants permissions to the file, and that means it has to either know exactly what other apps it will communicate with or assume that no app on the system is malicious. And some users (including me) want to play all their games through Bottles, because it takes up less disk space and makes it easier to fix any problems.

[GeorgesStavracas]

Can you please describe the use case behind this request?

Flatpak already supports forwarding files through the command line - see the --file-forwarding parameter of flatpak-run - which is effectively what is used e.g. when double clicking a file in the file manager. Is this not enough for Bottles?

[tpotancok]

Opening other apps with flatpak run requires --talk-name=org.freedesktop.Flatpak to run it on the host, which is insecure.

[Mikenux]

If you want to run a Windows game or application that was installed with a "Windows installer" that is not Bottles, Bottles will not be able to run it properly if it does not have access to all other files required by the application or game to run.

If the game/app is standalone, you may have a chance to run it with Bottles, provided there is a mechanism to access neighboring files. It's issue #463, but even if this portal takes shape, access to the number of files (in this case, files in subfolders) might eventually be limited, or some other mechanism will be needed.

If the game/app is not standalone, you will need access to other files that are not in the game/app installation folder (i.e. they can require additional files due to the installation of other things and/or have specific registry keys). To do this, it will then be necessary to access the entire Wine installation that does not belong to Bottles. That's another thing to deal with.

As for selecting the relevant executable file if the user chooses the wrong one, you can't choose the right one if, as already said, Bottles didn't access the other files before. All you can do − if the method is implemented in the portal − is probably to read the metadata of the file, check in a database if there is a matching application/game, then reopen the file chooser with the correct file pre-selected. However, even if the preselection of a file would be added, you will not be able to run your application or your game if Bottles does not have access to the other files...

[tpotancok]

It will run properly if the launcher installs the game into the bottle to begin with. And there's another unrelated use case for this, apps like Blender or GIMP that need their own importer/file opener can use the new method to get away from --filesystem=host.

[Mikenux]

Are you talking about opening a file with an app, but that app is opening that file with another app? Examples:

• User selects an EXE file with AppLauncher, but AppLauncher asks to open it with Bottles.
• User selects a RAW file with GIMP, but GIMP asks to open it in a RAW app (and the RAW app returns a compatible file to GIMP).

Is it that? If not, please clarify by giving the use case in detail, much like the examples I gave.