Roman Drahtmueller wrote:
Reserving ports or changing the "restricted" port range isn't the right approach for this.
First off: The restricted ports scheme has been invented for authentication based on trust of the root user of the client machine. It is used in the "r"-utilities such as rlogin and rsh. A client opens a port connection with a source port < 1024. Since the server knows that only root can do that, the server can be sure that /usr/bin/rlogin (with suid-root bit) was called on the client side. This is why the server trusts the client-provided information about the client user's identity. As you might imagine, this authentification mechanism is weak because trusting the client is exactly what you don't want - you want a proof.
Extending the restricted port area to the range around port 6000/tcp would not really improve security. You could keep users from starting X-servers, yes. But once there is one running, it binds to port 6000 (if it has display :0) on all available interfaces and interface addresses, and it stays there. It is not possible for another process to listen to the same addresses. This might have been your concern, right?
Wow, thanks a lot! If I understand it right, this would also apply to the xdm running on my machine, so it´s not possible for a user to listen to any local port (on the machine running xdm) used by xdm for an existing X-connection to an X-terminal. Thanks! Does this topic have a name? I mean, what should I search the web for in order to get info like this? (So I don´t need to post it here :) Thanks again! Anibal