How to make X11 requests from remote (ssh -X) apps only show remote windows?

[scorp123]

It aborts if the openssh-server is not installed on the client.

Never had that. And I've built thin clients with this thing so I am pretty sure I know what I'm doing...

[TheFu]

Are you saying that restricting remote X11 requests to windows from that remote host, requires running a full window manager from the remote machine?

No. What I'm saying is there are standards for what a WM should and should not do. Some of the new WMs do not conform to those standards and will either not work or work poorly.

[halogen2]

My window manager is Openbox and I can't find any setting for this in Openbox configuration?

I would prefer not to have a full remote desktop, is the type of filtering I'm seeking possible without that?

[TheFu]

But, all of this still does not answer my questions:

1) How can a remote application run over ssh -X even know about local windows?

Because it is the X/Server providing the list, not the remote X/Clients.

2) Is it possible to "turn this off" or otherwise get remote programs to only list windows from the machine on which they're installed?

Doubtful, since the X/Server is kinda the entire point.[/QUOTE]

[TheFu]

Thanks HermanAB, this is very helpful. I was not aware that using ssh -X flipped the notion of client/server.

Is it possible to configure the local X server to restrict remote requests to windows from the host issuing the request?

ssh uses the C/S as most people expect. The local machine is the client and the remote machines is the server.

X11 swaps that. The "server" is the machine you sit behind that does the displaying, sending keyboard and mouse events to the clients and all the remote programs (or local programs) are the X/Clients sending requests to the server. When we use ssh -X (or ssh -Y), all we are doing is

1. setting up a tunnel between the local and remote system
2. telling the X/Windows system we want X11Forwarding to be used through a specific X-display port
3. automatically setting a new DISPLAY environment variable, so the correct X-display port is used

It gets a little fuzzy around the mouse since there are different implementations. The X/Server knows the most about it, but it also knows which widget it is over and keyboard/mouse events are sent to the windowID and passed in the different layers to the most specific widget that will accept the specific Xevent type. There are software-mice and hardware-mice implementations. But none of this is usually important.

Gee - who'd a thunk all that X/Windows Developer training would finally payoff 25 yrs later? Now If I could just unload the (7) 2inch thick paper books on X11, that would be nice. The complete set came with the training.

[halogen2]

Doubtful, since the X/Server is kinda the entire point.

Thanks TheFu, that answers my remaining questions. It's weird that this type of filtering doesn't exist. Fortunately in my specific case all machines involved are trusted and under my administrative control, so at least this won't be a security problem.

For cases where this would be a problem, maybe I can work something with a Xephyr? Will experiment with that a bit before marking this solved.

* firejail --x11 --noprofile openbox and doing SSH from a Terminal launched inside the Xephyr does isolate the remote windows from (enough of) the local windows. Considering this thread as solved as it'll get. Thanks again all for the help

[TheFu]

X11 is designed to be network agnostic. Even the local X/Clients connecting to an X/Server on-the-same-machine use IP-sockets to communicate. The fact that the X/Client could be on a different machine and across the globe isn't really important for X.

It seems you've come to a technique that few people use. Basically, you want an integrated desktop, but without the desktop.
With most WMs, we can add menu items that run whatever commands we like. I have a few menuitems in my fvwm that run remote commands for me.
fvwm supports functions, so I have one that does remote ssh sessions. Here's the line that creates a menu entry to be clicked:

+ &istar FuncFvwmRloginSshRxvt  istar

And the terminal+ssh

AddToFunc FuncFvwmRloginSshRxvt \
  I Exec rxvt-unicode -fs 18 -bg black -fg white -fa 'Monospace' -name $0 -n $0 -title $USER@$0 -e ssh -X $0

I suppose I could find all the .desktop files on the remote system, pull those back to my workstation, then modify them to use ssh -X:
$ more ~/bin/thunderbird.sh

ssh -X regulus "/usr/bin/firejail /usr/bin/thunderbird" &

But for the stuff I use all the time, I've setup accel keys to launch them or just use tab-completion in a terminal to launch. That means I'm consistent in the things I've decided to run more protected. Clearly, I'm using ssh-agent and ssh-keys for authentication to remove the prompt hassles.