This is trivial to fix, at least for you.

  %corestaff ALL=NOPASSWD: /usr/bin/mailq "", \
                           /usr/sbin/exim -bp, \
                           /usr/sbin/exim -bpa, \
                           /usr/sbin/exim -bpc, \
                           /usr/sbin/exim -bpr, \
                           /usr/sbin/exim -bpu

That being said there definitely should be an automated way to check for incompatibilities between normal and rust sudo.

▲ dangistan202611 3 days ago | parent | next [-]

Before you know it, you will be needing a workaround for every replacement tool you use in Ubuntu. This is what makes it unacceptable.

▲ throw0101c 2 days ago | parent | prev | next [-]

> This is trivial to fix, at least for you.

Or one could just install (real) sudo instead of (fake) sudo.

Installing real sudo is something I will have to do when (if) we move to 26.04 because we need LDAP functionality, and fake sudo does not provide that.

▲ foxhill 3 days ago | parent | prev [-]

forgive me if i’m wrong. i don’t think you’ve ever had to administer more than a handful of machines. your “fix” is irrelevant.

> That being said there definitely should be an automated way to check for incompatibilities between normal and rust sudo.

yes. it’s called the bare minimum.

▲

9dev 3 days ago | parent | next [-]

I do manage more than a handful of machines, and that means using automation tools and IaC as much as possible, while avoiding humans using shells as much as possible. I’m struggling to enumerate a lot of use cases for a bespoke sudo configuration that shouldn’t be a proper setup.

▲

cyberax 3 days ago | parent | prev [-]

If you're using `sudo` for something beyond trivial `reboot`, you're doing something VERY wrong.

▲

dbt00 3 days ago | parent | next [-]

If you're not in the user community of a tool, having an opinion on whether or not the replacement should work doesn't seem like it should matter to you at all.

	▲	cyberax 3 days ago \| parent [-]
		The complexity of tools and the associated danger absolutely matters.

▲

baggy_trough 3 days ago | parent | prev | next [-]

What are you doing wrong?

▲

unrented7977 3 days ago | parent | prev [-]

Like.... apt-get?

▲

zenoprax 3 days ago | parent | next [-]

`sudo apt install my-custom-backdoor-script.deb`

With NOPASSWD you would also invite someone pulling a `.deb` via `curl` as part of a supply chain attack in a some non-descript NPM package via a git hook or something.

▲

cyberax 3 days ago | parent | prev [-]

So you want users to be able to install any package? So that the attack surface is now literally all the Debian archive?

Yeah, no.

You either use `sudo` when you want full root access or for something completely trivial.

▲

BHSPitMonkey 3 days ago | parent [-]

My sudoers is set up to let me run update and upgrade (with no args) without a challenge, but not install.

	▲	cyberax 2 days ago \| parent [-]
		I'm pretty sure I can b0rk the system by interrupting the upgrade in an inconsistent state. Or maybe inject some fun environment variables into the `apt-get` context. And I think you can launch the shell during conflict resolution for conffiles, giving you instant full access to the whole system? A more robust design is to have a systemd one-shot unit that users can activate (via a trigger file or sudo). So my point still stands and your example illustrates it perfectly. Either you use `sudo` for full root access or for something entirely trivial.