X server does not have an option to specify which address to listen on for TCP connections

[ornx]

why?
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: X server does not have an option to specify which address to listen on for TCP connections

[ornx]

‐‐‐ Original Message ‐‐‐
On Monday, May 11, 2020 8:18 AM, Attila Kinali  wrote:

> On Mon, 11 May 2020 01:41:11 +
> ornx o...@protonmail.com wrote:
>
> > why?
>
> Probably because it has never come up? X was intended to be used
> on desktops, which, usually, had only a single network interface.
> In case restrictions were needed, xauth/xhost provided the means
> to limit access. These days TCP is even disabled on most distros
> by default, for security reasons.
>
> Attila Kinali

>X was intended to be used on desktops
is this really true? my understanding is that X has always had a networked 
client/server model

my use case is that i need X to use TCP so that i can intercept its traffic 
with wireshark for debugging purposes, but i only need this server accessible 
on the loopback interface and specifically do not want it listening on any 
other interfaces for basic security reasons of not giving programs any network 
resources that they do not strictly need. using xauth/xhost seems insufficient 
for this purpose, because i already know that i do not want any external 
traffic to be able to access the server, why do i need to decide this at the 
application level instead of specifying it at the network level? what if there 
is a bug in the X authentication mechanism?
the workaround for this is also rather inconvenient and requires specialized 
knowledge, to prevent external network traffic from reaching X now involves 
writing firewall rules instead of merely setting a flag limiting the interfaces 
that X is listening on. it is also at odds with normal networking application 
behavior, i have actually never encountered a program before that listened on a 
port but did not allow to specify the listening interface

is the reason why this behavior has not been implemented in Xorg simply because 
nobody has thought to add it, or is there a specific reason that it was left 
out? if someone provided a patch implementing this behavior, would it have a 
chance of being merged?
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

EWMH specification doesn't say windows of type "dock" cannot be moved, but docks & WMs assume this

[ornx]

I am implementing EWMH support for a window manager. While reading the spec, I
noticed that it doesn't mention that programs with
_NET_WM_WINDOW_TYPE = _NET_WM_WINDOW_TYPE_DOCK cannot be moved, however, other
window managers and the dock programs themselves assume this. I could not find
any information in the EWMH or ICCC specification that specifies this behavior,
or that this behavior should be used for any other atoms with other dock-like
functionality (e.g., setting struts). I tested this with the dock program
"plank" and the window manager "awesome".

My questions then are:
* Is this an example of behavior that is part of a "de facto" standard for
  interactions between window managers and clients, that EWMH/ICCC are only
  subsets of? Or, have I simply misread the spec, and this behavior actually is
  specified in it somewhere?
* Is there a better resource for understanding how to correctly implement a
  window manager that supports these extensions than simply reading the source
  code of other window managers?

Many thanks,
- Ornxka
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s