On Wed, Jun 30, 2021 at 04:35:13PM +0200, to...@tuxteam.de wrote: > BTW: the problematic thing is called "xhost +", not "xhost +x", which > won't work... > > tomas@trotzki:~$ xhost + x > xhost: bad hostname "x" > > ...unless there's a host in your network named "x" :-)
xhost was mentioned by at least two different people, and they may not be on the same page as each other. One person mentioned "xhost +" (althogh I think they actually typoed it as "xhost+"), which is VERY bad indeed, and should never be used outside of an isolated private network. Another person mentioned "xhost +x" in which I took the final x to be a placeholder for a local network hostname. Doing this is less bad than "xhost +", because now you're only susceptible to keylogger attacks and so forth from the one host that you trusted, rather than from EVERY host. But still, this is not how remote X clients should be handled in this century. > Further, I don't think things are as bleak as Greg put them, since > by default, X doesn't listen on the network these days I mentioned this earlier. I think it got drowned out. My concern is that apparently there are people on this mailing list who are actively advocating that people should enable X's TCP listening and then enable xhost authorization, either globally or per-host. And these people are not giving adequate warnings about the security ramifications of their suggestions. Let alone the difficulty. To summarize, there are basically two sane approaches to remote X clients: 1) Run a Display Manager with XDMCP on the remote host, and allow users to connect to that from their workstations. The workstation will run an X server only; the rest of the session (all X clients including window manager) runs on the remote host. 2) Run a local X session including window manager on each workstation, but use ssh -X to the remote host to run specific X client programs. The first approach is a traditional "thin client" setup, and was common in some universities, back in the 1980s and 1990s. Full workstations capable of running both the X server *and* the client applications were expensive, so some organizations saved money by purchasing cheaper machines that would run only the X server. There is also a centralization benefit here, with all of the X clients running on a single host, that some administrators might have found useful. On the other hand, you had all your eggs in one basket. The second approach is more common now, with even the cheapest desktop machines being more than capable of handling both the X server and the X client applications. Having the window manager and other highly latency-susceptible programs running on the local machine, rather than over the network, gives a greatly improved experience for the user. This same consideration applies to web browsers, video players, etc.
