== My personal and biased view of _sudo_ versus _su_ I am an old fashioned Unix sysadmin so I have not really become very enthused about using _sudo_ as a replacement for _su_. I could make lots of excuses for this but what it boils down to is that I'm very used to using _su_ and I haven't felt like trying to readjust my entire set of reflexes and my environment to using _sudo_ instead. This doesn't mean that I don't like _sudo_ or that I don't use it at all. Instead I merely use _sudo_ as a replacement for what would otherwise be setuid programs (what I listed as the first face of _sudo_ in my entry on [[the three faces of _sudo_ ../unix/SudoThreeFaces]]). Part of this is what I see as [[a weaker _sudo_ security model ../unix/SudoSecurityModel]]. Part of this is because some amount of my work involves directly logging in to systems as root already, either because of [[the System V init environment leakage issue for restarting services ../linux/SystemdRestartEnvironment]] ([[also ../unix/SystemVInitGoodBad]]) or because we simply haven't set up user accounts on all of our systems (eg OpenBSD firewalls). But a lot of this is just habit, my cultivated usage patterns, and what I see as additional friction on the part of using _sudo_. One large part of my usage patterns is that I mostly don't intersperse operations that can be performed as an ordinary user and operations that need root powers. If I need to do a run of operations as root, adding _sudo_ to the front of all of them would be additional friction. If I only need to do one or two operations as root I'll usually then immediately discard the root shell, because I am a [[disposable usage pattern ../unix/PersistentVsDisposableUsage]] person. I almost always have root shells in their own windows and I mark those windows to make them very distinctive (I mentioned it [[here ASysadminTwitch]]); I think it would actually make me nervous to have _sudo_ powers in an otherwise unmarked and undistinguished shell session. (I do keep some root shells lingering around but these are for specific periodically repeated operations when I want to hold on to context and where repeatedly re-typing the root password would irritate me too much. They're also on my personal machines instead of any of our servers.) So on the whole I could switch to _sudo_ but it would be a pain in at least the short term, it would require changing how I do things, it might make the practical security issues somewhat worse, and I'm not convinced I would get much benefit from it. All of this neglects two and a half separate elephants in the room. The first elephant is that _sudo_ is less universally available than _su_ is. Every Unix machine we'll ever use at work has _su_; not all of them supply _sudo_ natively. The second elephant is the opinions of my co-workers. Partly because of the first elephant, my co-workers are highly likely to be no more receptive to switching to _sudo_ than I am. Switching by myself is somewhere between pointless and quixotic (even if I switch purely on my home and office workstations) and unless I persuade my co-workers not just to switch but to change work patterns like logging in directly as root it's not likely to give us any particular benefits (which of course makes it that much harder a sell to my co-workers). I don't necessarily think this is the ideal thing and I don't particularly advocate my approach here to anyone else. But my environment is what it is and today I feel like being honest about it. (One little pragmatic downside of switching to _sudo_ would be a drastic increase in sudo warning emails as we'd probably routinely fumble-finger the applicable password.) PS: Please note that if you're using _sudo_ audit logs to assign blame for particular bad things that happen on your machines, [[you're doing it wrong ../tech/HumanErrorNotRootCause]] ([[also SudoNotAuditingMechanism]]). This is one reason I don't find audit logs to be a particularly compelling advantage for _sudo_, especially because a crisis is both the time when you might most need audit logs (due to people's fallible memory under pressure) and also the time when people are most likely to wind up logging in directly as root because nothing else works.