Sandbox is too restrictive
Closed this issue · 23 comments
When using modes like merlin for ocaml, emacs has to be able to launch some external binaries. Same with the rust language server. And basically any feature that relies on executables outside of the sandbox.
Many plugins depend on the environment too. Having to use --env
for every variable is a big problem.
Would it be possible to allow emacs from flatpak to start basically any process?
flatpak run --talk-name=org.freedesktop.Flatpak org.gnu.emacs
Then from there you can do flatpak-spawn --host any-command
.
Sorry for being slow at responding, but anyway...
My impression is that it is pretty difficult to provide your usual host tools, most of them in /usr/bin, as-is inside the sandbox because /usr is where your runtime is. Even if you'd bind all of them into the sandbox, my guess would be that not all of them would be OK with replacing libraries of the host system with libraries of the runtime.
Given how completely emacs can be customized by the user, it seems possible that its functions for executing programs could be adjusted to go through flatpak-spawn by default. I have not tried it, though.
Also I am having trouble getting that advice from @TingPing to work, but still looking at why that is.
sh-4.4$ flatpak-spawn --host ls /
Portal call failed: org.freedesktop.DBus.Error.ServiceUnknown
sh-4.4$
From an emacs shell, this is what I get when calling flatpak-spawn
with any command.
From an emacs shell, this is what I get when calling flatpak-spawn with any command.
Either:
- You didn't add the talk permission I mentioned
- Your
flatpak
is very outdated
flatpak was outdated, updated it using the PPA, however the issue persists:
[📦 org.gnu.emacs ~]$ flatpak-spawn --host ls /
Portal call failed: org.freedesktop.DBus.Error.ServiceUnknown
[📦 org.gnu.emacs ~]$
And yes, this is launching with:
flatpak run --talk-name=org.freedesktop.portal.Flatpak org.gnu.emacs
$ flatpak --version
Flatpak 1.2.3
My mistake: --talk-name=org.freedesktop.Flatpak
My mistake: --talk-name=org.freedesktop.Flatpak
Ah okay, yeah this works. Was hoping to be able to get flyspell to work with this, but no luck there :\
A major problem with this issue is that for flyspell-mode
, there appears to be no way to modify how Emacs calls it without digging into how ispell
calls external progams.
In any case, I managed to get other packages like org-latex
working (for PDF export, which relies on pdflatex
) by placing this into my dotspacemacs/user-config
(I'm using Spacemacs on develop
branch, running 26.3 in VirtualBox running Debian):
(if (getenv "FLATPAK_ID")
(with-eval-after-load 'org
(setq org-latex-pdf-process (map 'list
(lambda (x)
(concat "flatpak-spawn --host " x))
org-latex-pdf-process))))
This code coexists pretty well with my other, non-virtualised and non-sandboxed instance of Emacs so far. I'm poking at how ispell
calls external functions and so far it looks like the function responsible is ispell-call-process
, and I'm debating whether I want to mess with it at all.
@muep would you accept adding --talk-name=org.freedesktop.Flatpak
in the default finish-args of the recipe?
@philn looks good to me. Now that I try the instructions for flatpak-spawn from a long time ago, I see that it works. Usually Fedora has a reasonably up-to-date flatpak, but I suppose that the functionality was still missing.
In current Fedora Silverblue it works :) Dunno about vanilla Fedora though.
👍 on the idea of patching Emacs to call flatpak spawn --host
when it runs within a Flatpak sandbox BTW... My 2 cents anyway.
My mistake: --talk-name=org.freedesktop.Flatpak
Ah okay, yeah this works. Was hoping to be able to get flyspell to work with this, but no luck there :\
Just wanted to add that changing from aspell
to hunspell
solved the issue for me. No other changes were needed.
(I was facing No word lists can be found for the language "en_US"
when trying to use ispell with aspell)
Ok flatpak spawn --host
does work with flatpaks.
But that doesnt fix the sandbox issue when trying to call some repo apps, etc.
I cant run anything in the emacs terminals (any terminals !) nor with dmenu.
How to fix this flatpak sandbox annoying behaviour ?
At this point, the flatpak sandbox just breaks emacs :(
I mean whats the point of a flatpak emacs then ?
@danrobi11 I think you're going to end up having to start the emacs terminal itself with flatpak-spawn --host ba/zsh
if that's possible.
I'm on Fedora 36 Silverblue, and have installed the latest Emacs from Flathub.
I had to manually override the talk-name
in order to get flatpak-spawn
to work. I did this on the host:
$ sudo flatpak override --talk-name org.freedesktop.Flatpak org.gnu.emacs
Is this step really necessary? Can't it be included in the recipe?
Thanks @joehakimrahme , I think it should be reasonable to include it. I will look at it as soon as convenient.
It appears this could also be solved if /usr/share/aspell
was available to Emacs. Unfortunately I have been unable to get this to work, even with flatpak run --filesystem=/usr/share/aspell:ro … org.gnu.emacs
. Even then, from within Emacs's term
or shell
I get:
sh-5.1$ ls -al /usr/share/aspell
ls: cannot access '/usr/share/aspell': No such file or directory
sh-5.1$ flatpak-spawn --host ls /usr/share/aspell
aspell.compat
…
sh-5.1$ aspell dicts
[no output]
sh-5.1$ flatpak-spawn --host aspell dicts
en
…
As a work-around, if you have hunspell
installed, you can change ispell-program-name
to hunspell
, and it may work for you, since /usr/share/hunspell
and /usr/share/locale
do appear to be available to Emacs (at least with my installation).
(--filesystem=…
having no effect filed as flatpak/flatpak#5040.)
Sorry for taking my sweet time, I have had limited time for improvements in recent weeks.
@joehakimrahme @posita , #50 has the change for enabling the use of flatpak-spawn --host
. Once it has gone through the build queue, the PR should have a link to a test build.
While I guess someone will want to use flatpak-spawn --host
in any case, does it seem that it does not address this problem with aspell? Do you think this change would still be useful?
Thanks for the change.
I'm still a bit new to flatpak. I have previously overriden tlak-name manually, do you think it will affect me (and others) updating to the new build?
#50 was merged and got at least the flatpak-spawn
route working for me. I think this can be closed now, let's do new issues if there are other ideas to help with interacting with the host system.
@tariqk not sure if this is still interesting to you but it might interesting to others so I will leave this comment here.
There is a texlive sdk extension. One can then add that texlive sdk extension as an environment variable.
For installing the sdk one can follow the instructions at https://flathub.org/apps/org.freedesktop.Sdk.Extension.texlive
flatpak install flathub org.freedesktop.Sdk.Extension.texlive
The version of texlive should be the same as the version of freedesktop in the manifest according to this comment.Then one can maybe add that extension as an environment variable either each time the flatpak is run as shown here (I did not try that and have no or little experience with that syntax) https://www.reddit.com/r/emacs/comments/1bhmvie/comment/kvhmyjz/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button or as mentioned in that link adding the environment variable (more specifically, adding it as a configuration). One can add the environment variable with flatseal or using the command below:
MAYBE IMPORTANT NOTE: In the command below I used --user but depending on how you installed emacs, you might not have to use that I am not sure
flatpak override --env=FLATPAK_ENABLE_SDK_EXT=texlive --user org.gnu.emacs
You might also need to change the PATH emacs uses [EDIT: at least that was need for turning equations to images in .tex files]. I saw somewhere that the PATH that emacs uses in the GUI is not necessarily the PATH that is used in the shell that ran it. You might have to add the following configuration to emacs:
(setenv "PATH" (concat (getenv "PATH") ":/usr/lib/sdk/texlive/bin/x86_64-linux:/usr/lib/sdk/texlive/bin/" ))
The first time I modified the PATH in an emacs configuration file I was able to get image previews of latex equations but the second time after I tried removing stuff that I thought might not be needed, I got an error that still appeared after I tried to manually revert back to the configuration I had. The error was something like or exactly the text below:
PDF2DSC sentinel: Wrong type argument: arrayp, nil
I was able to fix that error by following the answer here but I modified the path and the command I used was
(setq preview-gs-command "/usr/lib/sdk/texlive/bin/gs")
[EDIT:
If you are using org-mode to view latex files it seems that it is necessary to modify exec-path
so that emacs can find latex and dvipng. I used the following in my configuration file
(add-to-list 'exec-path "/usr/lib/sdk/texlive/bin/x86_64-linux")
]