flathub / org.gnu.emacs

https://flathub.org/apps/details/org.gnu.emacs
16 stars 17 forks source link

Sandbox is too restrictive #14

Closed Khady closed 1 year ago

Khady commented 5 years ago

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?

TingPing commented 5 years ago

flatpak run --talk-name=org.freedesktop.Flatpak org.gnu.emacs

Then from there you can do flatpak-spawn --host any-command.

muep commented 5 years ago

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.

DarkArc commented 5 years ago
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.

TingPing commented 5 years ago

From an emacs shell, this is what I get when calling flatpak-spawn with any command.

Either:

DarkArc commented 5 years ago

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
TingPing commented 5 years ago

My mistake: --talk-name=org.freedesktop.Flatpak

DarkArc commented 5 years ago

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 :\

tariqk commented 4 years ago

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 4 years ago

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

muep commented 4 years ago

@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 4 years ago

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

philn commented 4 years ago

:+1: on the idea of patching Emacs to call flatpak spawn --host when it runs within a Flatpak sandbox BTW... My 2 cents anyway.

tcpaiva commented 3 years ago

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)

danrobi11 commented 3 years ago

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 ?

LeifAndersen commented 2 years ago

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

joehakimrahme commented 2 years ago

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 2 years ago

Thanks @joehakimrahme , I think it should be reasonable to include it. I will look at it as soon as convenient.

posita commented 2 years ago

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

posita commented 2 years ago

See https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/issues/1242.

muep commented 2 years ago

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?

joehakimrahme commented 2 years ago

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 1 year ago

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.

userrand commented 1 week ago

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

]