Why would you be running sudo in production? A production environment should usually be setup up properly with explicit roles and normal access control.

Sudo is kind of a UX tool for user sessions where the user fundamentally can do things that require admin/root privileges but they don't trust themselves not to fat finger things so we add some friction. That friction is not really a security layer, it's a UX layer against fat fingering.

I know there is more to sudo if you really go deep on it, but the above is what 99+% of users are doing with it. If you're using sudo as a sort of framework for building setuid-like tooling, then this does not apply to you.

▲

acdha 4 hours ago | parent | next [-]

> A production environment should usually be setup up properly with explicit roles and normal access control.

… and sudo is a common tool for doing that so you can do things like say members of this group can restart a specific service or trigger a task as a service user without otherwise giving them root.

Yes, there are many other ways to accomplish that goal but it seems odd to criticize a tool being used for its original purpose.

▲

pphysch 3 hours ago | parent [-]

PSA for anyone reading this, you should probably use polkit instead of sudo if you just want to grant systemd-related permissions, like restarting a service, to an unprivileged user.

It's roughly the same complexity (one drop-in file) to implement.

	▲	acdha 2 hours ago \| parent [-]
		I’d broaden that slightly to say you should try to have as few mechanisms for elevating privileges as possible: if you had tooling around sudo, dzdo, etc. for PAM, auditing, etc. I wouldn’t lightly add a third tool until you were confident that you had parity on that side.

▲

throw0101a 4 hours ago | parent | prev | next [-]

> Why would you be running sudo in production? A production environment should usually be setup up properly with explicit roles and normal access control.

And doing cross-role actions may be part of that production environment.

You could configure an ACME client to run as a service account to talk to an ACME server (like Let's Encrypt), write the nonce files in /var/www, and then the resulting new certificate in /etc/certs. But you still need to restart (or at least reload) the web/IMAP/SMTP server to pick up the updated certs.

But do you want the ACME client to run as the same service user as the web server? You can add sudo so that the ACME service account can tell the web service account/web server to do a reload.

▲

bigstrat2003 4 hours ago | parent | prev | next [-]

Almost everyone is running sudo in production.

▲

bloqs 3 hours ago | parent | prev | next [-]

the fact this is a reply to the content in the parent just demos the complete lack of social skills or empathy many in this community are known for

▲

bobmcnamara 4 hours ago | parent | prev [-]

Auditing.