Safely Open an X Display with xhost

You will inspect the current X access list, allow one trusted host when you genuinely need it, and restore access control afterwards. That is the useful part of xhost. The dangerous part is that one short command can let everyone connect to the display.

This guide uses xhost 1.0.9 from Debian package x11-xserver-utils version 7.7+10build2, installed on this machine. Allow about ten minutes. You need a running X server and a shell with the correct DISPLAY environment variable. Most checks are ordinary user commands; no example needs sudo.

Checkpoint: This guide changes the X server's live access list, but does not edit a configuration file. Keep your current local terminal open until the final verification succeeds.

1. Confirm which xhost you are using

Start with the executable and its built-in usage message. These commands are read-only:

$ command -v xhost
/usr/bin/xhost
$ xhost -help
usage: xhost [[+-]hostname ...]

The installed manpage describes the command as an X server access-control program. It takes names prefixed with + to add and - to remove. With no argument, it reports the current state and allowed entries.

Do not confuse the package version with the X server version. The client is version 1.0.9 here, while the server, display manager and authentication setup may come from different packages.

2. Check the display before changing anything

Ask xhost for the current list without passing an access-control option:

$ xhost

Your output will differ. Look for the access-control state and the entries that are allowed. Save the output somewhere private if you need to reproduce the previous list exactly:

$ xhost > /tmp/xhost-before.txt
$ sed -n '1,20p' /tmp/xhost-before.txt

If you see unable to open display, stop here. Check printf '%s\n' "$DISPLAY" and your session's X authentication rather than trying random display names. The installed xhost client does not provide a -display option: according to its bug notes, -display would be interpreted as removing a host named display.

3. Add one trusted host, only for the required task

Use a host name or address that you have verified. Replace trusted-host.example with the actual machine, and keep the leading plus sign:

$ xhost +trusted-host.example

The plus sign grants that host permission to make new connections. Existing connections are not the thing being tested here, so verify the list immediately:

$ xhost

The exact listing format depends on the X server and name resolution. The useful checkpoint is that the trusted host appears and access control still reports as enabled.

Security boundary: A host entry is not a fine-grained application permission. A client that can use the permitted host can attempt to connect to the display, and X access may expose input, windows or other client-visible state. Do not use a broad network range or a host you do not control.

4. Remove the temporary entry

As soon as the remote task finishes, remove the entry with the matching minus form:

$ xhost -trusted-host.example

Check that it has gone:

$ xhost

Removing an entry denies new connection attempts. It does not break clients that are already connected. Close or terminate an unwanted client separately if it connected while the temporary permission existed.

If the removal command fails, do not repeatedly toggle access for convenience. Recheck the spelling, the DISPLAY value and the output captured before the change. If you removed the wrong entry, add that exact entry back only after confirming that it belongs to your original list.

5. Understand the tempting global switches

The bare plus command is not the same as adding one host:

$ xhost +

This turns access control off for everyone. It is a security-sensitive, live change and should not be used as a general fix for an authentication problem. Restore restriction with a bare minus command:

$ xhost -

Turning access control back on does not necessarily recreate the list you had before. If you need specific entries, inspect the result and add only the ones you can justify. The safest recovery is to keep a record of the original output before making changes.

There is one particularly nasty trap in the manpage: you can remove the current machine itself. After doing so, further connections, including attempts to add the machine back, may be refused. Resetting the server, which breaks all connections, is then the documented way to restore local access. Do not test that case on a live desktop.

6. Prefer user-based authentication for regular use

xhost provides a rudimentary host-based privacy control, suitable only for a limited single-user workstation situation. The manpage points to user-based mechanisms and to the X protocol's authentication support for environments needing stronger protection.

For a local user, the server-interpreted form can be more specific than the broad LOCAL: family. The documented shape is:

$ xhost +si:localuser:USERNAME
$ xhost -si:localuser:USERNAME

Replace USERNAME with an actual local account name. This is still a live access-list change, not a replacement for properly managed X authentication. For remote access, investigate xauth, SSH X forwarding or your desktop's normal authentication path before weakening host access.

7. Know what the machine stores

The X server stores network addresses for ordinary host entries, not necessarily the host names you typed. If a host's address changes while the server is running, add the new address and remove the old one. A name that resolves to multiple IPv4 or IPv6 addresses can therefore produce more than one access-list entry.

For persistent initial access control, the manpage describes /etc/X<display-number>.hosts, where the display number is substituted into the file name. Editing that file is an administrative configuration change and may affect future X server starts. It is outside this temporary workflow, so do not create it merely to make one remote command work.

Done means