Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request]: Support FileTransfer portal (secure drag and drop between sandboxed Linux apps) #30650

Open
3 tasks done
vchernin opened this issue Aug 20, 2021 · 2 comments

Comments

@vchernin
Copy link

vchernin commented Aug 20, 2021

Preflight Checklist

Problem Description

Electron should support the FileTransfer portal as it will let users drag & drop and copy-paste files/folders securely to sandboxed Linux apps.

Flatpak and other sandboxed Linux packages (eg. Snap) use XDG Desktop Portal to securely communicate between the sandbox and the host. This is crucial for sandboxed apps, as otherwise apps need to be given unilateral access to the host, notably file system access.

XDG Desktop Portal's FileChooser portal was recently implemented in Electron: #19159. This means a sandboxed app could have no unilateral file system access, but still open the file picker, select, and "upload" a file/folder to an app without letting that sandboxed app know about anything other than the picked file/folder.

However, the FileChooser portal does not cover dragging & dropping a file into an Electron app (or vice versa) or secure copy-paste. The FileTransfer portal is what is needed for drag & drop and copy-paste to work securely between the host and the sandbox.

Proposed Solution

Implement support for the FileTranfer portal in Electron. This might be best done in Chromium and then reused in Electron. The libportal library could eventually be used here but it does not yet support FileTransfer.

The FileTranfer portal can be used by both sandboxed and non sandboxed apps, as discussed here: flatpak/libportal#33

Alternatives Considered

Workaround by giving sandboxed apps unilateral permission to access the host's filesystem. This is the status quo today for many apps, and is very much an anti-goal for sandboxed apps.

Additional Information

For this implementation to be useful, other apps are also required to support the FileTransfer portal. So if a user drags a file from a file manager to an Electron app (with FileTransfer implemented), that file manager must support FileTransfer too, otherwise it will still not work.

As of 2021-08-19, the only other toolkit/framework that supports the FileTransfer portal is GTK4.

Bugs for other toolkits/frameworks:
GTK 3, QT

@Mart-Bogdan
Copy link

By the way, it just have being implemented in GTK3 two months ago https://gitlab.gnome.org/GNOME/gtk/-/commit/9f81db139d03a1b7d9bdac298fb6424a14d645cb

This commit can be used as reference.

@threema-danilo
Copy link

This is a major usability issue right now. Thanks to the file system portal, opening a file works even if the file system permission is very limited. However, drag & drop is broken in that case: The application gets the file system path on the host system, but permission to that file is denied.

From a usability perspective, it would be best to just default to --filesystem=host. However, from a security perspective, that's not a great idea. A file transfer portal implementation should resolve this issue.

GarboMuffin added a commit to flathub/org.turbowarp.TurboWarp that referenced this issue Apr 15, 2024
In 3def183 we removed
--filesystem=home because we fixed file:// parsing on argv.
However, this broke being able to drag & drop costumes, sounds,
sprites, extensions, etc. in as Electron does not support the file
transfer portal.

These features are very convenient, enabled by default, and
used in a lot of places throughout the app. Having it be broken by
default is a bad experience.

Upstream bug: electron/electron#30650
Previous discussion: TurboWarp/desktop#569
GarboMuffin added a commit to flathub/org.turbowarp.TurboWarp that referenced this issue Apr 15, 2024
In 3def183 we removed
--filesystem=home because we fixed file:// parsing on argv.
However, this broke being able to drag & drop costumes, sounds,
sprites, extensions, etc. in as Electron does not support the file
transfer portal.

These features are very convenient, enabled by default, and used
in a lot of places throughout the app. Having it be broken by default
is a bad experience.

Can't use a more specific --filesystem=... because we don't know
where users will place their project files. Some people put them on
the desktop; or in downloads; or in documents; or in a custom folder
in their home directory.

Upstream bug: electron/electron#30650
Related discussion: TurboWarp/desktop#569
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants