An X11-forwarded ssh session authorises the remote client to talk to your local X server without you ever running an xhost command. Which mechanism provides that authorisation?

LPIC-1 Exam 102-500, objective 106. User interfaces and desktops hard

Machine-checked — no person has signed for it. This question was read against the source cited below by an automated pass, which found no contradiction. That is a weaker claim than it sounds: the same kind of process wrote the question, so it can confirm its own mistake.

Treat it as a good draft rather than as settled fact, and read the source below before you rely on it. It is not used in mock exams here — only questions a person has signed for are.

How these questions are written — where each question comes from, what the verification ledger records, and what happens when one is found wrong.

The options

Not correct The Xorg configuration file /etc/X11/xorg.conf, which lists permitted remote hosts.

Wrong. xorg.conf configures the server's hardware and layout — screens, input devices, monitors, drivers, modules. It holds no client authorisation list, and on modern systems it is often absent entirely because Xorg autodetects.

Not correct The user's ~/.Xresources file, read at session start.

Wrong. ~/.Xresources holds X resource defaults for client appearance and behaviour, such as XTerm*background. It is loaded into the server's resource database with xrdb and has nothing to do with access control.

Not correct The DISPLAY variable itself, whose value doubles as a shared secret.

Wrong. DISPLAY is only an address telling the client where the server is. It carries no secret and is routinely visible in the environment of every process.

Correct A per-display authorisation cookie stored in the user's ~/.Xauthority file and managed with xauth.

Correct. X uses MIT-MAGIC-COOKIE-1 tokens kept in ~/.Xauthority. ssh generates a cookie for the proxy display on the remote host and writes it into the remote user's Xauthority file, so the forwarded client can authenticate to your local server.

Why

There are two families of X access control. Host-based control with xhost trusts an entire machine and is coarse and unsafe. Cookie-based control is per-user and per-display: a random token lives in ~/.Xauthority, and a client must present it. `xauth list` shows the stored entries, `xauth extract`/`xauth merge` move them between hosts, and `xauth remove` deletes one. If ~/.Xauthority is unwritable or removed, forwarded sessions typically fail with "cannot open display".

Where this comes from

Cited
LPI exam objective 106.1
What it says
Awareness of X authorisation using xhost, xauth and the .Xauthority file.

Practise this

Reading one question is not practice. The trainer will draw a short set from objective 106 and space the ones you get wrong.

Practise LPIC-1 Exam 102-500

More questions on this objective

All questions on User interfaces and desktops

Practise LPIC-1 Exam 102-500