in reply to Peter G

This is not entirely accurate; there are plenty of times when sudo does not require a password even in the default config. And there’s the nopasswd option built-in already which would already do that portion of this request.

It sounds like the OP wants to use sudo as a Molly-guard. There’s nothing wrong with that, although it may not be the right tool for the job.

in reply to dontblink

Do you mean the delay between when you need to re-enter the superuser password?

I found this via an LLM:

To change the delay before needing to re-enter your sudo password, follow these steps:

  1. Open the terminal and run:
    sudo visudo
  2. Locate the line:
    Defaults env_reset
  3. Add the following line below it:
    Defaults timestamp_timeout=<time-in-minutes>

    Replace <time-in-minutes> with the desired timeout in minutes (e.g., 30 for 30 minutes). Setting it to 0 requires a password every time, while a negative value disables the timeout entirely.
in reply to dontblink

sure. first, configure sudo to be passwordless, or perhaps just to stay unlocked for longer (it's easy to find instructions for how to do that).

then, put this in your ~/.bashrc:

alias sudo='echo -n "are you sure? "; for i in $(seq 5); do echo -n "$((6 - $i)) "; sleep 1; done && echo && /usr/bin/sudo '

Now "sudo" will give you a 5 second countdown (during which you can hit ctrl-c if you change your mind) before running whatever command you ask it to.

This entry was edited (1 year ago)
in reply to Arthur Besse

In terms of security, an alias can be easily overridden by a user who can even choose yo use another shell which will not read .bashrc.

So this solution cannot force/require the user to comply to the delay requirement.

I was thinking maybe with a PAM module the delay can be achieved but I haven't found one that readily does that. Maybe OP needs to implement one 😀

in reply to dontblink

I can’t find anything that quite fits your requirements.

Putting a NOPASSWD option on your sudo config should cover the removal of the password requirement, but this may be ill -advised; it is probably wiser to increase the timestamp_timeout duration.

The intentional delay is tougher, and for that it looks like you’d need to write a PAM module. pam_faildelay is very close to what you need, you’d just need to make it produce a delay on success as well as failure.

This entry was edited (1 year ago)
in reply to dontblink

This entry was edited (1 year ago)