A library Linux foothold is non-root. The tester still wants a user-level forward. What privilege constraint should they remember conceptually?
Select an answer to reveal the explanation.
Short Explanation
No root does not mean no pivoting—it means you work with the seats you are allowed to sit in. Low ports are often reserved; user-level listens usually live higher up. Plan the forward around the account’s real limits instead of wishing the OS would look the other way.
Full Explanation
On a library Linux foothold that is non-root, the tester wanting a user-level forward must remember that non-root binds are limited; plan forwards around what the user account can actually listen on. Non-root users cannot freely bind privileged low ports without additional rights. Port forwards are not impossible without Domain Admin—Domain Admin is a Windows directory concept and is not the universal gate for Linux user-level forwards. Linux does not ignore listen privileges once any shell exists; OS DAC and capability rules still apply. Exam caveat: privilege constraints shape which pivot sockets you can create. Operational check: check effective uid/capabilities, choose high ports the account can bind, confirm the forward works for the intended library service, and escalate privileges only if separately authorized and necessary. In municipal operations, record the rationale in the engagement notes so future testers and city defenders understand which approach was chosen and which failure modes the rejected options would create for civic services. Re-validate the same judgment after the next change window so the control still holds under the city’s current tooling, identity posture, and RoE amendments.