flatpak-run doesn't work over X11 Forwarding #397
Comments
|
Yeah, the sandboxing support for X11 is tied to using unix domain sockets, so it will override the DISPLAY env var with an in-sandbox version of the unix domain X11 socket. I think we should detect this case and leave the display env var alone, but it should work already if you re-set the DISPLAY variable in the sandbox. |
|
|
|
I'm not saying this is a great solution, but can you verify that this works: |
|
That still doesn't work, but if I run it without the semicolon I get: |
|
Apparently it's something specific to Polari because it works for gnome-builder. The manifests look pretty similar so I'm not sure what the relevant difference is. |
|
Since org.gnome.Polari replaces the home dir, it loses access to the .Xauthority file. This should probably get addressed in a much cleaner way. |
|
I am having a similar problem with the monodevelop application found here: http:https://www.monodevelop.com/download/linux/ @jarfil 's solution did not work for me: This issue reproduced with versions 0.6.12, 0.6.14 on OS Centos 7 and ubuntu 16.10 |
|
@bdonnahue You may have a stale link to an older .Xauthority file in your .xauth dir which you may have to remove. It's probably better to copy it instead of just linking to it anyway, so I've updated my recipe accordingly. |
|
Perhaps it's too late but I got same problem for running gedit:
work for me |
Unfortunately when I try that with gimp I get: |
|
tygerlord solution worked for remote running of AndroidStudio too running remotely on Linux mint distro. |
|
I wonder if we could detect a non-local X11 and set up some proxy using ncat instead. Then it could work even without network access. |
|
I tried the command @tygerlord posted. It worked for me. I use host based authentication for the XServer. I use a remote X connection for displaying apps of a Linux VM on the Windows host system. This is the best integration into the Windows desktop I could figure out until now. I say this just in case anyone wonders why people still use remote X connections. |
|
Just leaving a note here for users of Octave. Note: I tried e.g. the alternative below without success. Note: Also reported issue at the Octave issue tracker: https://savannah.gnu.org/bugs/index.php?56550 However, the command as per @tygerlord did work (although graphics seems unusually slow): |
|
FWIW I had success with: |
|
Same work-around is needed when using flatpak on WSL2 with an X-Server package like GWSL. |
|
Same issue here: But every other thing that is not flatpak works. |
As with non-path-based AF_UNIX sockets, both of these are going to require --share=network to be enabled, so print a warning if it isn't. We don't automatically enable --share=network, because that elevates the privileges of apps that would otherwise have entered a new network namespace, but regular users of remote X11 can choose to enable it with `flatpak run --share=network` or `flatpak override --share=network`. Resolves: flatpak#397 Signed-off-by: Simon McVittie <[email protected]>
As with non-path-based AF_UNIX sockets, both of these are going to require --share=network to be enabled, so print a warning if it isn't. We don't automatically enable --share=network, because that elevates the privileges of apps that would otherwise have entered a new network namespace, but regular users of remote X11 can choose to enable it with `flatpak run --share=network` or `flatpak override --share=network`. Resolves: #397 Signed-off-by: Simon McVittie <[email protected]>
As with non-path-based AF_UNIX sockets, both of these are going to require --share=network to be enabled, so print a warning if it isn't. We don't automatically enable --share=network, because that elevates the privileges of apps that would otherwise have entered a new network namespace, but regular users of remote X11 can choose to enable it with `flatpak run --share=network` or `flatpak override --share=network`. Resolves: flatpak#397 Signed-off-by: Simon McVittie <[email protected]> (cherry picked from commit db885e0)
As with non-path-based AF_UNIX sockets, both of these are going to require --share=network to be enabled, so print a warning if it isn't. We don't automatically enable --share=network, because that elevates the privileges of apps that would otherwise have entered a new network namespace, but regular users of remote X11 can choose to enable it with `flatpak run --share=network` or `flatpak override --share=network`. Resolves: flatpak#397 Signed-off-by: Simon McVittie <[email protected]> (cherry picked from commit db885e0)
As with non-path-based AF_UNIX sockets, both of these are going to require --share=network to be enabled, so print a warning if it isn't. We don't automatically enable --share=network, because that elevates the privileges of apps that would otherwise have entered a new network namespace, but regular users of remote X11 can choose to enable it with `flatpak run --share=network` or `flatpak override --share=network`. Resolves: flatpak#397 Signed-off-by: Simon McVittie <[email protected]> (cherry picked from commit db885e0)
As with non-path-based AF_UNIX sockets, both of these are going to require --share=network to be enabled, so print a warning if it isn't. We don't automatically enable --share=network, because that elevates the privileges of apps that would otherwise have entered a new network namespace, but regular users of remote X11 can choose to enable it with `flatpak run --share=network` or `flatpak override --share=network`. Resolves: flatpak#397 Signed-off-by: Simon McVittie <[email protected]> (cherry picked from commit db885e0)
As with non-path-based AF_UNIX sockets, both of these are going to require --share=network to be enabled, so print a warning if it isn't. We don't automatically enable --share=network, because that elevates the privileges of apps that would otherwise have entered a new network namespace, but regular users of remote X11 can choose to enable it with `flatpak run --share=network` or `flatpak override --share=network`. Resolves: #397 Signed-off-by: Simon McVittie <[email protected]> (cherry picked from commit db885e0)
|
Hmm, my Xauthority file ends up with "FamilyInternet" entries which just store the IP address in binary rather than an ascii hostname (see https://github.com/freedesktop/libXau/blob/master/README) :- xauth_entry_should_propagate() currently doesn't seem to handle that at all :( |
|
Totally horrible hack - bwrap-wrapper: then |
|
Given doing remote X other than through ssh forwarding is probably pretty niche these days, and likely to become more obsolete as Wayland takes over, perhaps a simple option (or environment variable) to copy or bind mount in a custom Xauthority would be OK? People using X like that are likely to have understand about xauth anyway. |
Please open a separate issue for this, rather than replying to a closed issue. X11 forwarding in general can be made to work since #4706, but X11 forwarding in your specific situation does not.
Given this, the maintainers of Flatpak (whose available time is limited) are unlikely to treat implementing this as a high priority. If you can propose a concrete implementation as a PR, then reviewing it is a smaller time investment for the maintainers than implementing it, making it more likely to happen. (Please open an issue describing the problem in as much detail as you can before trying to implement a solution, though - a detailed description of the problem or steps to reproduce it are extremely useful context for a reviewer to be able to assess whether a proposed solution fixes the problem as stated.)
Please open a merge request if this is something you want to implement. I personally am not intending to implement this, because if I did, I would have to wait for another maintainer to become available to review it - but I'll try to find time to review a PR if someone opens one. |
In a shell with X11 Forwarding enabled,
flatpak rundoesn't work.In the output below, the Gtk-WARNING at the bottom is the only relevant part (the rest appears when running locally).
The text was updated successfully, but these errors were encountered: