[acdha]

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

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]

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.

[pphysch]

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.

[acdha]

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.

[yjftsjthsd-h]

What's the benefit?

[Hendrikto]

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