Open baermathias opened 4 years ago
It can never work, its sandboxed. The only thing it could do is download the file and then open it with your default editor.
So the solution is to give the FileZilla Flatpak version certain access to a directory or app?
You'd have to patch it to use flatpak-spawn --host
to escape the sandbox and execute apps on the host.
Why can't it be released the same way the original app is working?
Because flatpak
is a sandbox. It isolates this app from other apps.
How about handling it in a similar way as snap does? With a snap I would get a message before the editor would be executed:
Allow opening file? Allow snap "filezilla" to open file "/path/to/code_editor_name"? This dialog will close automatically after 5 minutes of inactivity.
That could be plausible and would be a discussion to have here: https://github.com/flatpak/xdg-desktop-portal/
But any solution there would require source changes to Filezilla to use said portal.
It also introduces complications since what exists in the sandbox != what exists on the host.
I'd like to precise regarding org.filezillaproject.Filezilla settings :
usr/bin/gedit which is pre-filled in File editing box doesn't work, nor php usr/bin/libreoffice in Filetype associations box
Also instead of usr/bin/gedit, selecting "use default system text editor for text files" (or similar : I use a french version) doesn't work either : An assertion failed !
ASSERT INFO:
./src/common/filefn.cpp(1609): assert "!szFile.empty()" failed in wxFindFileInPath(): empty file name in wxFindFileInPath
BACKTRACE: (null)
Thanks
Hi, I have no idea how it's implemented but if you take Pitivi video editor in Flatpak for instance, once your project is rendered it asks you to choose an application to play the video (see screenshot below).
Note sure if it can help.
Thanks.
Hi, I have no idea how it's implemented but if you take Pitivi video editor in Flatpak for instance, once your project is rendered it asks you to choose an application to play the video (see screenshot below).
Note sure if it can help.
Thanks.
They are using the OpenURI portal https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.portal.OpenURI
I've just upgraded my system to Ubuntu 20.04, and I've installed FileZilla as a flatpak.
Unfortunately, I now have this same problem.
If it's not possible to get FileZilla as a flatpak to recognise the editor, it makes the flatpak release useless to me. I'll have to revert to the PPA, which I really prefer to avoid (PPA clutter). EDIT: There's no PPA; you have to download from the website, which makes it even harder :(
Given how much easier snap is to install and use than flatpak, maybe we could see FileZilla released a a snap?
And easier solution (For Debian 11 KDE at least) is to download filezilla from the website (https://filezilla-project.org/download.php?show_all=1), extract it, place it somewhere (say ~/.bin/) and then create a new menu entry pointing to the binary (~/.bin/FileZilla3/bin/filezilla).
In my use case, I agree with @paddylandau. Not being able to automatically open files in a text editor is a flaw. However, I would say that the flaw lies in Filezilla not recognizing the system default more than the ability to customise the text editor.
If it's of any help to you, I have figured out a simple workaround. (Edited 2023-08-16 and 2023-08-22 with new information.)
In my case, I use the text editor gedit
, which is located on on my default path.
My workaround is as follows. Remember that when you change the sandbox settings, you need to close FileZilla before it takes effect.
Give FileZilla permission to bypass the sandbox. Naturally, you have to trust FileZilla before you do this. Either Flatseal > Session Bus > Talks > add org.freedesktop.Flatpak
, or issue the following command in the terminal:
flatpak --user override --talk-name=org.freedesktop.Flatpak org.filezillaproject.Filezilla
You also have to let FileZilla access /tmp
, because it seems to ignore $TMPDIR. Either Flatseal > Filesystem > Other files > /tmp
, or issue the following command in the terminal:
flatpak --user override --filesystem=/tmp org.filezillaproject.Filezilla
Create a script named filezilla-edit
. Ensure that it is executable. This script contains just two lines:
#!/usr/bin/env bash
flatpak-spawn --host gedit "${@}"
In FileZilla, go to Edit > Settings > File editing > Use custom editor > /path/to/filezilla-edit
(replace /path/to
with your actual path to filezilla-edit
).
This does the job.
Notes about the script:
bash
, e.g. sh
(if necessary, modify the syntax as appropriate). But I found that when I didn't specify a shell, it didn't work; I don't know why.gedit
with whichever GUI text editor you prefer.I'll link to this from Flathub as well.
unfortunately the solution above didn't work in my case. I could open local files with the editor set in filezilla-edit, but I couldn't edit the files on the server. So I dropped the flatpak-filezilla and used the very old .deb version ... a nice mess.
unfortunately the solution above didn't work in my case. I could open local files with the editor set in filezilla-edit, but I couldn't edit the files on the server.
I've had another look at my setup, and I notice that I had added /tmp
to the flatpak permissions. Removing that prevents the editor from loading the remote file.
I have edited my previous comment; see point 2.
Please try again to see if it works.
oh, wow - this fast :)))) Thank you @paddylandau , this did the trick. It works and I don't have to use the old filezilla. Thanks a lot :+1:
And I forgot to mention that I had to close filezilla so the changes could take effect! Maybe you could mention this in your solution - to close or "restart" filezilla after the changes.
Thank you @paddylandau , works for me now too :) However, I'd like to use Gnome Text Editor to edit but when I replace gedit
with flatpak run org.gnome.TextEditor
in the script, the file opens in it but it's empty!
Would appreciate any help or advice with this. Thanks.
Update:
No worries. Had to also give Gnome Text Editor access to /tmp
in Flatseal.
Edit: The instructions presented in this comment are incorrect. Check https://github.com/flathub/org.filezillaproject.Filezilla/issues/40#issuecomment-1899398896.
Thank you @paddylandau for the tips, they directed me to a simpler solution.
/usr/bin/flatpak-spawn --host gedit %f
$XDG_RUNTIME_DIR/.flatpak/$FLATPAK_ID
, so after checking the contents of $XDG_RUNTIME_DIR (echo $XDG_RUNTIME_DIR
- in my example /run/user/1000
), the full command to type as Use custom editor is:
/usr/bin/flatpak-spawn --host gedit /run/user/1000/.flatpak/org.filezillaproject.Filezilla%f
Summary:
flatpak override --user --talk-name=org.freedesktop.Flatpak org.filezillaproject.Filezilla
/run/user/1000
with the result of echo $XDG_RUNTIME_DIR
):
/usr/bin/flatpak-spawn --host gedit /run/user/1000/.flatpak/org.filezillaproject.Filezilla%f
Thank you, @Matige . Unfortunately, this doesn't work for me!
I haven't used FileZilla to edit a file for a long time, so before I looked at your alternative, I tested to see if my solution still worked.
It didn't! I could successfully edit a local file, but not a remote file. In other words, I was failing to access the file downloaded into /tmp
.
I suspect that my new problem (accessing the remote file) is because when I first created the solution, I wasn't using the Flatpak version of Gedit, whereas now I am. I think that Gedit needs an extra permission to access Flatpak's pseudo $TMP
, but I don't know how to go about that. I'll have to test when I have more time.
Naturally, I have tested your method. Unfortunately, it's even worse: With your method, I can access neither the local nor the remote file.
The problem with the local file is because you have specified the full path starting with /run
, but of course that's not where local files are. The custom editor should be use just %f
, not the full path, otherwise local files cannot be edited.
Note: My $XDG_RUNTIME_DIR
is the same as yours: /run/user/1000
.
I'll post back here if I manage to work out how to use the Flatpak version of Gedit with FileZilla.
@paddylandau, I fully agree with you. My solution isn't working properly. I have explored the issue too little.
For systems other than Windows and Mac, FileZilla sets the location of temporary files as follows:
#else
if (!ret.SetPath(GetEnv("TMPDIR"))) {
if (!ret.SetPath(GetEnv("TMP"))) {
if (!ret.SetPath(GetEnv("TEMP"))) {
ret.SetPath(L"/tmp");
}
}
}
#endif
The TEMPDIR
, TMP
and TEMP
environment variables are checked. If the directory exists, it is set as the directory for temporary files. Otherwise /tmp
is set.
Flatpak has introduced support for shared temporary directory as of version 1.11.1 (https://github.com/flatpak/flatpak/commit/b65b3f6eadd51bd6600df2c0d07f902a552163d2). It maps the directory $XDG_RUNTIME_DIR/.flatpak/$FLATPAK_ID/tmp
and in the container it is visible as /tmp
. This is the reason why editing external files (stored in the /tmp
directory) worked in my workaround.
It would seem that the solution is to set the TEMPDIR
environment variable to $XDG_RUNTIME_DIR/.flatpak/org.filezillaproject.Filezilla/tmp
. However, it turned out that flatpak app doesn't have access to this directory, so FileZilla will set the temporary directory to /tmp
. As a result, the edited files are downloaded to $XDG_RUNTIME_DIR/.flatpak/org.filezillaproject.Filezilla/tmp
, but the /tmp
directory is passed as the %f
parameter, so an empty file is opened.
So I reached out to the Flatpak documentation (I should start there).
One of Flatpak’s main goals is to increase the security of desktop systems by isolating applications from one another. This is achieved using sandboxing and means that, by default, applications that are run with Flatpak have extremely limited access to the host environment. This includes:
- No access to any host files except the runtime, the app,
~/.var/app/$FLATPAK_ID
, and$XDG_RUNTIME_DIR/app/$FLATPAK_ID
. Only the latter two being writable.
[...]
If an application uses
$TMPDIR
to contain lock files you may want to add a wrapper script that sets it to$XDG_RUNTIME_DIR/app/$FLATPAK_ID
.
In that case, the solution is to set the TEMPDIR environment variable for FileZilla:
flatpak override --user --env TMPDIR="${XDG_RUNTIME_DIR}/app/org.filezillaproject.Filezilla" org.filezillaproject.Filezilla
Now the edited files are downloaded to ${XDG_RUNTIME_DIR}/app/org.filezillaproject.Filezilla
, this directory is also passed as parameter %f
to the editor. Of course, in this case we set Use custom editor to /usr/bin/flatpak-spawn --host gedit %f
.
Final summary
flatpak override --user --talk-name=org.freedesktop.Flatpak org.filezillaproject.Filezilla
flatpak override --user --env TMPDIR="${XDG_RUNTIME_DIR}/app/org.filezillaproject.Filezilla" org.filezillaproject.Filezilla
/usr/bin/flatpak-spawn --host gedit %f
Reflections
One might ask why not simply grant FileZilla access to the /tmp
directory. This breaks the idea of Flatpak sandboxing. The /tmp
directory is accessible to everyone with 777 chmod.
There is still the issue of accessing the temporary directory from another Flatpak application (such as gedit installed as flatpak). The flatpak application only has access to its own directory, so gedit can access $XDG_RUNTIME_DIR/app/org.gnome.gedit
, but not $XDG_RUNTIME_DIR/app/org.filezillaproject.Filezilla
. Therefore, the opened file will be empty. I don't know if there is any correct way to solve this problem. Personally, I see two solutions:
flatpak --user override --filesystem="${XDG_RUNTIME_DIR}/app/org.filezillaproject.Filezilla" org.gnome.gedit
@Matige — Thank you so much! Thanks to your investigation, I have managed to make it work. Here are the steps:
Allow FileZilla to bypass the sandbox.
flatpak override --user --talk-name=org.freedesktop.Flatpak org.filezillaproject.Filezilla
Ask FileZilla to use its own pseudo-/tmp
.
flatpak override --user --env TMPDIR="${XDG_RUNTIME_DIR}"/app/org.filezillaproject.Filezilla org.filezillaproject.Filezilla
If you use the flatpak version of Gedit, allow it to access FileZilla's temporary folder.
flatpak override --user --filesystem="${XDG_RUNTIME_DIR}"/app/org.filezillaproject.Filezilla org.gnome.gedit
Set FileZilla to call Gedit. Note that you don't need to add %f
to the command, as the files are added automatically.
FileZilla > Edit > Settings > File editing > Use custom editor > /usr/bin/flatpak-spawn --host gedit
Hi, any chance to have this feature working out of the box of the flatpak version ? Thanks !
No, the entire feature is incompatible with running in a sandbox.
No, the entire feature is incompatible with running in a sandbox.
Thanks for the answer.
However I thought that a portal could be used as shown in https://github.com/flathub/org.filezillaproject.Filezilla/issues/40#issuecomment-613315991 ?
If the feature is redesigned upstream, sure some things can work. But that isn't how it currently works and would have less flexibility than how it currently works.
Thanks
I am using FileZilla flatpak version
3.45.1
and getting the following error when trying to open a file or changing the custom editor:The file 'index.html' cannot be opened: The associated program (/usr/bin/code) could not be found. Please check your filetype associations.
Even though I can run
/usr/bin/code
from the command line. It also worked in the old version, which was anapplication directory
and not aflatpak
.