Hacker News Reader

Comment by oconnore | Hacker News Reader

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.

View on HN

> 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.

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.

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.

Privilege escalation (superuser capabilities) and RBAC ought to be viewed differently, IMO.

There's a place for true superusers, such as auditing, where no stone should be too heavy. But mostly for securing systems, we want RBAC, and sudo is abused as a pile-driver where only a mallet was needed. Polkit is more of a proper policy toolkit.

That’s a valid choice. I’m just saying that you should pick ideally one tool for that class of work. For example, if you support one tool for Mac and Linux users that’s probably worth more than supporting two similar tools even if one of them is better.

What's the benefit?

You can acquire permission on-demand and scoped more tightly.

> 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.

In your example certbot is given permission to write to /var/www/.well-known/acme-challenge and to write certs somewhere. Your web server also has permission to read those files too.

There is no need for the acme client and web server to run as the same user. For reloads the certbot user can be given permission to just invoke the reload command / signal directly. There does not need to be sudo in between them.

Almost everyone is running sudo in production.

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

Auditing.

bro i just want to apt install gimp :(

Reply on news.ycombinator.com