Description of problem:
When logging in via ssh, DBUS_SESSION_BUS_ADDRESS is set to the same value as for local console logins (e.g., unix:path=/run/user/1000/bus), rather than creating a separate session bus for the forwarded X session.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Try to run a GNOME application via ssh; e.g.
ssh -X -Y gnome-terminal
ssh -X -Y eog
If the user is logged in on the console, the gnome-terminal window appears on the console instead of the display where ssh was invoked (but with $DISPLAY set to "localhost:11.0" or similar, so any X applications launced from the gnome-terminal window are displayed on the ssh client's display).
If the user was not logged in on the console, gnome-terminal fails to start; it reports:
# Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: Error calling StartServiceByName for org.gnome.Terminal: Timeout was reached
after a delay of approximately 25 seconds, and the xdg-desktop-portal launched by the new session crashes with a segmentation fault.
Applications run via SSH forwarding should not depend on or interfere with the user's console session.
Starting a new dbus instance for the SSH session, e.g.,
ssh -X -Y beta@beta0
[beta@beta0 ~]$ dbus-launch --exit-with-session gnome-terminal
will launch gnome-terminal on the correct display. (Note that doing this in one step via
ssh -X -Y beta@beta0 dbus-launch --exit-with-session gnome-terminal
causes X applications launched from within the gnome-terminal to fail with "Unable to init server: Could not connect: Connection refused." as ssh closes the X11 channel after setup for some reason; this behaviour is not directly related to this bug report.)
Note that updating the DBUS activation environment via
dbus-update-activation-environment DBUS_SESSION_BUS_ADDRESS DISPLAY XAUTHORITY
in the SSH session is not a practical workaround: it will make applications launched over the forwarded X connection work, but will cause subsequent side effects with the user's session on the console. As far as I can determine, forwarded X sessions need a separate DBUS session, but it's not clear to me what mechanism is appropriate for creating it.
Thank you for the bug report. It would be great if this would be working out of the box correcly.
I did some digging in the history and there were already requests to do something like this years ago (see bug #484171, which asked for dbus forwarding, even with a proof of concept). For security reasons, I do not think it is a good idea to share the whole dbus with the potentially untrusted server so I believe starting the new session dbus should be preferred here.
The question is when should it happen and what application should take care of that. I do not think this should be hardcoded in the OpenSSH, since we have other ways to customize what is running upon the ssh login.
The DBUS_SESSION_BUS_ADDRESS is set by the pam_systemd to current local user session bus, which is what one usually wants when opening a new terminal locally. But usually not what you want when connecting remotely. I will ask around the desktop/gnome/systemd developers if they have some ideas how this can be solved.
Yet I reckon that has nothing to do with DBUS actually, but with gtk+ forcing Wayland display
to "wayland-0" if no WAYLAND_DISPLAY is set.
To force the remote gtk+ apps to use X11 tunnelling via ssh (instead of Wayland), use GDK_BACKEND=x11, e.g.:
1. $ ssh -Y remotehost
2. $ GDK_BACKEND=x11 gnome-calculator → ends up on "local" X11 display
Also, please note that gnome-terminal is a bit of a special case here, because it is indeed running a daemon (gnome-terminal-server) which takes care of opening multiple terminal windows from the same process, so even with forcing X11, the window will still open on the remote host (unless a new instance of gnome-terminal-server is started locally).
1. $ ssh -Y remotehost
2. $ GDK_BACKEND=x11 /usr/libexec/gnome-terminal-server --app-id my.remote.Terminal &
3. $ GDK_BACKEND=x11 gnome-terminal --app-id my.remote.Terminal
I don't think Olivier Fourdan's assessment is accurate for my case; setting GDK_BACKEND does not appear to affect the symptom for me. "ssh -X -Y beta@beta0 GDK_BACKEND=x11 eog" produces the same 25-second delay and segfault in xdg-desktop-portal (when the user is not also logged into the console) as without the variable.
I don't know whether this is relevant, but my RHEL8 Beta installation is installed on a Hyper-V virtual machine, and the console is running Xorg, not Wayland (I'm guessing because Wayland doesn't support the emulated video card, but that's not necessarily relevant to this bug; the point is that Wayland does not appear to be in the picture).
Starting gnome-terminal-server does cause gnome-terminal to appear on the correct server, but there's still the same 25-second delay. GDK_BACKEND is also irrelevant to the behaviour for that case.
I agree that forwarding dbus through the SSH connection doesn't feel like the right solution: among other concerns, I don't know whether it's reasonable to assume that the SSH client's system is running DBUS, let alone a compatible instance.
I recognize that this may not strictly be an openssh issue, and I appreciate you reaching out to the other subsystem developers. My impression was that dbus instances were intended to be per-session, not per-user, but I'm not up to date on current design criteria.
Try setting "NO_AT_BRIDGE=1" as well, does it help with the 25 seconds delay?
Setting NO_AT_BRIDGE=1 also has no effect.
I strongly suspect that there is a connection between the delay and the fact that xdg-desktop-portal is segfaulting: during one instance, journalctl reported, e.g.:
Mar 15 10:51:06 beta0.ecf.utoronto.ca systemd: Starting Portal service (GTK+/GNOME implementation)...
Mar 15 10:51:06 beta0.ecf.utoronto.ca xdg-desktop-portal-gtk: Unable to init server: Could not connect: Connection refused
Mar 15 10:51:06 beta0.ecf.utoronto.ca xdg-desktop-por: cannot open display:
Mar 15 10:51:06 beta0.ecf.utoronto.ca systemd: xdg-desktop-portal-gtk.service: Main process exited, code=exited, status=1/FAILURE
Mar 15 10:51:06 beta0.ecf.utoronto.ca systemd: xdg-desktop-portal-gtk.service: Failed with result 'exit-code'.
Mar 15 10:51:06 beta0.ecf.utoronto.ca systemd: Failed to start Portal service (GTK+/GNOME implementation).
Mar 15 10:51:31 beta0.ecf.utoronto.ca xdg-desktop-por: Failed to create file chooser proxy: Error calling StartServiceByName for org.freedesktop.impl.portal.desktop.gtk: Timeout was reached
Mar 15 10:51:31 beta0.ecf.utoronto.ca xdg-desktop-por: g_dbus_interface_skeleton_set_flags: assertion 'G_IS_DBUS_INTERFACE_SKELETON (interface_)' failed
Mar 15 10:51:31 beta0.ecf.utoronto.ca xdg-desktop-por: invalid (NULL) pointer instance
Mar 15 10:51:31 beta0.ecf.utoronto.ca xdg-desktop-por: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
Mar 15 10:51:31 beta0.ecf.utoronto.ca xdg-desktop-por: g_dbus_interface_skeleton_export: assertion 'G_IS_DBUS_INTERFACE_SKELETON (interface_)' failed
I can provide more detailed logs if you are unable to reproduce the issue yourself, but I think this is tangential to the actual problem--the crashing of xdg-desktop-portal looks like a symptom rather than a cause, as it is trying to connect to a nonexistent X server associated with the dbus instance. Note that the delay goes away if the same user is logged into the console via X, since the application can connect to the xdg-desktop-portal service (for the wrong X server instance), but this fact is not useful as a mitigation.
(In reply to Jakub Jelen from comment #1)
> The DBUS_SESSION_BUS_ADDRESS is set by the pam_systemd to current local user
> session bus, which is what one usually wants when opening a new terminal
> locally. But usually not what you want when connecting remotely. I will ask
> around the desktop/gnome/systemd developers if they have some ideas how this
> can be solved.
Well connecting remotely isn't really the relevant factor, it's whether or
not remote display forwarding is enabled.
I mean I actually would want it to use the local bus and local display if
i'm not trying to forward the app to another machine.
Probably pam_systemd shouldn't set DBUS_SESSION_BUS_ADDRESS if it's a remote
connection and if DISPLAY is in the environment.
But that's not sufficient to fix the problem since glib and i guess libdbus
both will just use the well known name of the user bus if DBUS_SESSION_BUS_ADDRESS
So I think I agree, a fresh bus should get started, and DBUS_SESSION_BUS_ADDRESS should
get set, if openssh is doing remote display forwarding.
(In reply to Ray Strode [halfline] from comment #7)
> Well connecting remotely isn't really the relevant factor, it's whether or
> not remote display forwarding is enabled.
> I mean I actually would want it to use the local bus and local display if
> i'm not trying to forward the app to another machine.
I do not think either option is to use local dbus. It will always be a remote dbus,
but in one case it will be the default and in the other dedicated session dbus.
> Probably pam_systemd shouldn't set DBUS_SESSION_BUS_ADDRESS if it's a remote
> connection and if DISPLAY is in the environment.
I am not sure whether the DISPLAY environment variable is propagated to the pam_systemd.
If I am right, it is set only to the executed process, but pam is running in separate
thread, which might limit the pam_systemd decission options.
> But that's not sufficient to fix the problem since glib and i guess libdbus
> both will just use the well known name of the user bus if
> isn't set.
> So I think I agree, a fresh bus should get started, and
> DBUS_SESSION_BUS_ADDRESS should
> get set, if openssh is doing remote display forwarding.
Lets see what is the systemd developers take on this.
to be clear, i meant "local to the app" not "local to the operator". poor word choice, indeed, but the crux of my point is if the display is forwarded, there should be a isolated message bus, imo. if the display is not forwarded, the app should use the user bus.
i dont think pam_systemd should be the thing starting the isolated bus mind you, but i'll let the systemd guys chime in.