[AStonesThrow]

I am not sure how passwords are relevant to the pointless chaining of two distinct commands, rather than invoking a straightforward "sudo -s".

People writing "sudo su" are simply imitating a common StackExchange idiom without knowing why.

"su" requires passwords unless invoked by root. "sudo" may be configured to permit/deny specific commands. So if you write that, then you're saying 'become root via the sudoers(5) config and then fork, exec, become root again via the setuid binary "su", in order to run an interactive shell.'

It's a poor habit to be promoting, because it assumes things about the configuration and suggests that "su" is equal to other particular "sudo" maintenance commands, when the point is simply to drop into a root shell, which is a facility provided directly by "sudo", if you'd only read the manual page and learn its options.

Nothing will stop you from invoking "sudo -s" without a password, without another fork/exec, without another suid utility carrying a significantly different authentication model.

[tetris11]

Doesn't "sudo -s" keep the current user's environment variables as opposed to "sudo su"?

I admit that in the context of doing "ls /sys/module" it's likely not a huge problem, but I do (in my gut) feel that for running an elevated command, it's cleaner to just drop in as actual root, instead of masquerading as root.

[AStonesThrow]

> if you'd only read the manual page and learn its options.

[tetris11]

> Depending on the security policy, the user's PATH environment variable may be modified, replaced, or passed unchanged to the program that sudo executes.

Essentially a "maybe, depending on what your OS policy is", proving that your comments are less than helpful.

[AStonesThrow]

Well, you are moving the goalposts like crazy, considering you were just executing a simple command with your original example, but let me search it and demonstrate the rest of it, rather than your Ctrl-F find one option in question:

https://manpages.ubuntu.com/manpages/noble/en/man8/sudo.8.ht...

     -E, --preserve-env

     --preserve-env=list

     -H, --set-home

     -i, --login

     -s, --shell

 The sudoers policy subjects environment variables passed as options to the same restrictions as existing environment variables with one important difference.  If the setenv option is set in sudoers, the command to be run has the SETENV tag set or the command matched is ALL, the user may set variables that would otherwise be forbidden.

I am not sure what is meant by "masquerading as root" -- effective UID rather than real UID? "sudo" should set both to the target; there is no masquerading, even if you end up in a root shell with features of the invoking user's environment, those relevant variables should've been adjusted in the process.

So what you're proposing to do is to escalate privilege using "sudo"s security model and configuration, which may add, suppress, or alter environment variables, as well as SELinux and resource limits and cgroups or whatever, and then have a second go-round through "su" may alter the environment further, making for an unpredictable interaction. Hopefully it's all harmonized through PAM, but all you wanted is an interactive shell. Why try to justify this copy-paste idiom?

In fact, I could rewrite your original snippet as

  sudo ls /sys/module

Why are you even opening an interactive shell to do one simple command? If that's all you want, then learn and use the appropriate idiom for it. "sudo(8)" was originally designed to run one-off commands without invoking that shell. In fact, security experts will tell you not to leave root shells open at any time. If you can run a "sudo command" and return to your user shell, then that is best practice.

[tetris11]

Hey, thanks for the one extremely useful comment!