RHCSA Prep: The sudo Command Isn't What It Seems
The laborant user is raising an alarm: when they run sudo <command>, everything looks like
it works — no errors, no permission denied — but the commands are not actually running with root
privileges. Files that should be owned by root end up owned by laborant. Privileged operations
complete silently without requiring a password. Something in the shell environment is intercepting
sudo before the real binary ever runs.
Investigate the shell environment on rocky-01, find what is shadowing the sudo command, trace
it to its source, and fix it permanently so that future login sessions behave correctly.
Hint 1 — Where to start
The RHCSA audit procedure says: before trusting any command, check what the shell thinks that command is. Start with the command that's behaving strangely.
Hint 2 — What to check
There is more than one way for a shell to intercept a command name: aliases, shell functions, and
$PATH ordering. The type builtin tells you which mechanism is active. Try type sudo in the
laborant user's interactive shell.
Hint 3 — Finding the source
Once you know what is intercepting sudo, find where it is defined. Use:
grep -n 'sudo' ~/.bashrc ~/.bash_profile ~/.profile 2>/dev/null
Shell functions injected via startup files survive across sessions. The fix must remove the definition from the file — unsetting it in the current session alone is not enough.