A water utility Linux host mounts an NFS share exported with no_root_squash. During privilege-escalation enumeration, how should the tester interpret that export option?
Select an answer to reveal the explanation.
Short Explanation
Picture a shared filing cabinet that trusts whoever walks up wearing a "root" badge from another building. no_root_squash means the NFS server does not demote remote root to a nobody-style user, so client root often keeps powerful rights on the share. That is a classic Linux priv-esc adjacent finding worth highlighting—not a harmless speed tweak.
Full Explanation
On a water utility Linux host, an NFS export with no_root_squash is a privilege-escalation-adjacent risk: root on a client can often map to root-equivalent access on the share, undermining the usual squashing of remote root. Testers should interpret that option as a serious trust boundary issue during enumeration.
It is not merely a read-only performance flag about mount latency. It does not by itself prove Kerberos ticket forwarding for every NFS client. It is not a Windows-only SMB signing setting to ignore on Linux targets.
Exam caveat: impact depends on who can mount the export and whether client root is attacker-controlled; still flag no_root_squash as high-interest on civic file services.
Operational check: review export options for utility shares, note no_root_squash and client allowlists, and report residual risk if root squashing is disabled. Recommend root_squash (or equivalent) unless a documented exception exists with compensating controls. In municipal operations, record the rationale in the engagement notes so future assessors know which control was chosen and which failure modes the rejected options would create for city services. Re-validate after the next maintenance window that the same finding class still applies under the estate's current patch and configuration baseline.