3 ms·
> 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
by acdha 9mo ago
> 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 9mo agoPSA 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 9mo agoI’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 9mo agoPrivilege 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 9mo agoThat’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 9mo agoWhat's the benefit?
- Hendrikto 9mo agoYou can acquire permission on-demand and scoped more tightly.