A transit agency service runs as root and loads its configuration from a directory writable by a low-privilege user. What privilege-escalation theme does that represent?
Select an answer to reveal the explanation.
Short Explanation
If root reads a config file you can edit, you are basically writing tomorrow morning's instructions for the boss. That writable-path-plus-privileged-reader pattern is a textbook Linux priv-esc theme. Keep hunting those paths instead of assuming confinement already fixed it.
Full Explanation
A transit agency service that runs as root and loads configuration from a directory writable by a low-privilege user creates a classic writable-config privilege-escalation class: the unprivileged user can alter runtime behavior, inject commands via config features, or redirect trusted paths that root will honor.
This does not prove systemd timers cannot be abused. It is not a sign the service is automatically confined by seccomp with no residual risk. It is not a cue to stop local enumeration and consider only network pivoting.
Exam caveat: review both the config directory ACL and whether the service reloads attacker-controlled content without integrity checks.
Operational check: identify root services and their config paths, verify write permissions for non-root users, and document influence over privileged startup. Recommend root-owned configuration stores and least-privilege service accounts for transit workloads. 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.