Home / Alt manpages / xserver(1)

  • xserver(1)
  • User command
  • linux

Run Xserver Safely: Display Selection, Access and Recovery

You will finish with a safe way to choose an X display and review the two controls that matter most before starting a server: which transports it listens on and which clients it authorises. This guide uses the installed Xserver(1) manual page, labelled xorg-server 21.1.11, from package xserver-common version 2:21.1.12-1ubuntu1.6. The generic command is normally started by a display manager, not by typing X at a normal desktop prompt.

Allow about 15 minutes. You need a shell and an existing X display manager or server-specific command. The examples below are configuration and inspection examples. They do not start a display server, change access control or disconnect a running desktop.

1. Check which server you actually have

Xserver is the generic name in the manual. It describes common server options, while the real executable is usually a server-specific binary such as Xorg, selected by a display manager. Check the installed package and read the local manual before copying an option into a service definition:

$ dpkg-query -W -f='${Package} ${Version}\n' xserver-common
xserver-common 2:21.1.12-1ubuntu1.6
$ man Xserver

On this machine the manual page is present, but neither X nor Xorg is on the current shell's PATH. That is not proof that a display manager has no server binary: service environments and package layouts can differ. Find the command used by your display manager before editing it.

Checkpoint

You know the package version and have identified the actual server command or service that will consume the options.

2. Choose a display without colliding with another server

The display number follows a colon. The default is display 0, so a second server needs another number, for example :1. Each display also has a Unix-domain socket under /tmp/.X11-unix/. Do not pick a number merely because it looks unused; check both the running processes and socket directory first:

$ ps -ef | grep '[X]org\|[[:space:]]X[[:space:]]'
$ ls -l /tmp/.X11-unix/
$ ls -l /tmp/.X11-unix/X1 2>/dev/null || true

If the launcher can pass a file descriptor, -displayfd is safer for an automatically selected display. The server tries higher display numbers until it finds a free one, then writes the selected number as a newline-terminated string to that descriptor. When -displayfd is used, the manual says -pn is ignored.

For a hand-written test command, use the server-specific launcher and an explicit display only after checking that the session is disposable:

$ SERVER_COMMAND :1 [server-specific-options]

Replace SERVER_COMMAND with the command your system documents. Do not paste the brackets. Starting a real server can take over a display, claim devices and interrupt your graphical session, so it is not a harmless verification step.

3. Keep network listening disabled by default

The generic manual lists transport names such as tcp, inet, inet6, unix and local. To prevent TCP clients from reaching a server, use the documented option:

-nolisten tcp

The option can be repeated for different transports. A local desktop normally needs a local transport, not a network listener. If a deployment genuinely requires TCP, document why, restrict it outside the X server as well, and pair it with authorisation. Enabling TCP with -listen tcp is a security-sensitive change because an X client that connects can control the display.

Do not confuse -nolisten tcp with access control. It removes one route to the server, but it does not decide what an already-authorised local client may do.

4. Use an authorisation file for clients

Pass a private authorisation file with -auth. The server reads the file when it starts and before the first connection after a reset. If it contains records, clients must present one of those records. The manual names MIT-MAGIC-COOKIE-1 among the supported protocols and points to xauth(1) for maintaining the file.

-auth /run/user/1000/xauthority-for-display

Use the path produced by your display manager or session manager, not a filename copied from another machine. Protect it as a credential: do not put it in a world-readable directory, paste its contents into tickets, or expose it in backups without a reason. If you need to inspect the current records, use xauth as the owning user and avoid printing the file into shared logs.

Never use -ac on a shared or reachable display. It disables host-based access control and permits any host to modify the access-control list. The manual describes it as a testing option and warns to use it with extreme caution. Remove it from the launcher to undo that change, then restart the server through the normal display manager if the running server was started with it.

5. Understand host-based access and its limits

When no other authorisation mechanism is being used, the initial host list includes the local host and entries from /etc/X<n>.hosts, where <n> is the display number. For display :1, the documented file is therefore /etc/X1.hosts. A line can contain a hostname or a family-qualified name such as inet:bigcpu.

Changing that list is state-changing and normally requires elevated privileges. Before editing a file in /etc, make a root-owned backup and confirm the exact display number. The safer recovery is to remove an entry you added and restart the display manager or server using its ordinary configuration process. Do not use xhost + as a quick fix: it disables host-based checks and makes the display broadly reachable through any enabled transport.

Host access is not a capability system. The X protocol does not inherently restrict window operations, so a client that can connect may have broad control of the screen. Prefer cookie authorisation and a local-only transport, and treat a successful connection as a security boundary crossing.

6. Diagnose startup without making a second problem

For a startup failure, first check the display number, the authorisation-file path and the transport options. The server normally permits it to continue when it cannot establish every well-known socket, provided it establishes at least one; this is the default behaviour of -pn. -nopn makes failure to establish all of them fatal. Do not add -nopn merely to make an error look clearer if you do not understand which socket is expected.

Use the server's service logs and standard error to find the rejected socket or unreadable file. If the server needs a font path, -fp accepts a comma-separated list of font directories. The installed default includes directories below /usr/share/fonts/X11/ and built-in fonts. Avoid replacing that path wholesale unless you have checked that every required font source remains available.

Signals also have operational consequences. SIGTERM makes the server exit cleanly. SIGHUP closes connections, frees resources and restores defaults, so sending it to a production display is service-disrupting. Test recovery on a disposable display or during a planned maintenance window.

Done means

  • The real server command and installed package version are known.
  • The display number is free, or -displayfd is used by the launcher.
  • TCP listening is disabled unless there is a documented requirement.
  • An authorisation file is supplied and protected as a credential.
  • -ac and broad xhost access are absent outside controlled tests.
  • Any restart or signal test has a recovery plan and a maintenance window.