flathub/org.gnu.emacs

Sandbox is too restrictive

Closed this issue · 23 comments

Khady commented

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.

muep commented

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.

philn commented

@muep would you accept adding --talk-name=org.freedesktop.Flatpak in the default finish-args of the recipe?

muep commented

@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.

philn commented

In current Fedora Silverblue it works :) Dunno about vanilla Fedora though.

philn commented

👍 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?

muep commented

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.)

muep commented

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?

muep commented

#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")

]