Sure, it always bothered me that guides show whole lists of commands prefixed by sudo, instead of teaching people to disable the timeout and use "sudo -i" or "sudo -s" to get their stuff done. See also the fact that OSX ships with tty_tickets disabled.
Still, unless one is sure that the sudo being invoked really is sudo, disabling the timeout won't be enough.
it always bothered me that guides show whole lists of commands prefixed by sudo, instead of teaching people to disable the timeout and use "sudo -i" or "sudo -s" to get their stuff done
That gets to the philosophy of what sudo is used for in the first place. Back when sudo was experiencing a big upswing in popularity, it was a way to avoid having a root shell open at all. Forcing the user to type sudo before every command reminds them they're acting as root.
If you advocate for only using sudo as a different way to authenticate for a root shell that's cool and all (I often use it like that too), but you're going to run into a disagreement around the nature of sudo.
Sure, although I never found that reason to hold much ground given that in reality most distros ship with accounts that can open a shell (instead of having a list of allowed commands) and have the timeout not set to zero, so any security benefit that would come from not using "sudo -s" is pretty much voided.
And I'm skeptical that having users type sudo a bunch of time when they add a PPA and install a program somehow results in greater awareness, but this is purely an opinion of mine.
The other big reason for using sudo is the ability to change policy wrt which users can be root without changing root password everytime, and that clearly is true.
When you have multiple commands to run, chances are that only some of them require root privilege. Prefixing only those with `sudo` instead of executing all of them in a root shell allows you to reduce damage, should the "normal" commands are typed wrong or have bugs.
> That gets to the philosophy of what sudo is used for in the first place. Back when sudo was experiencing a big upswing in popularity, it was a way to avoid having a root shell open at all. Forcing the user to type sudo before every command reminds them they're acting as root.
I do not think that is accurate. As I remember it, sudo gained popularity because it provided better control over access to the "root password" for teams of administrative staff. sudo was lightyears easier and provided much more fine-grained control than figuring out how to design POXIX groups.
1) A mechanism to provide better control over access to root privileges where administrative access must be shared between multiple users.
2) An auditing mechanism to record both operations completed as the root user, as well as failed attempts to perform operations as root (usually authentication failures).
3) A way to remind the user that commands are running as root, as well as a way to avoid accidentally running commands as root, since you're never (without "sudo -i" or "sudo -s" or similar) at an actual root shell.
If you're using "sudo -i"/"sudo -s" all the time, you don't lose anything for #1, and losing #3 is mostly just an inconvenience (it's an extra layer of protection, but it's not even really foolproof even with sudo). Losing #2 (auditing) can be a big deal, though, because, if everything's happening at a root shell (rather than via the sudo command), you lose the audit log that traces what's being done at root. Gaps like that in audit logs should be an indicator that something bad might've happened, but you can't make that assumption if you're routinely doing it yourself, too.
Still, unless one is sure that the sudo being invoked really is sudo, disabling the timeout won't be enough.