1

I need that a new user could execute sudo without any request of password, because this user has in crontab a .sh that uses sudo for some commands.

I created a new user on my ubuntu server 16.04 x64

adduser my-user sudo
gpasswd -a my-user sudo

Then using visuo i added this line, based on this question

my-user ALL=(ALL) NOPASSWD : ALL

Then rebooted

After reboot I logged in using my-user and tried to do sudo clear, but it ask me the sudo password.

NOTE: I've added the crontab using crontab -e my-user so I suppose my script is executed as my-user. In fact, the crontabbed script crashes telling me in the log about a sudo request of password. I really need to execute the script in this way to be able to create file with my-suer as owner.

Please tell me if some steps/lines were not needed and how to make able my-user to execute sudo without password request.

Thanks

PS: I seen this question, but I'm not able to make it working so I need a more precise explanation, because my situation is different: i'm running a crontab script and I need it do not ask for sudo password

  • 1
    crontab scripts are supposed to be executed as root, they shouldn't need sudo – Sergiy Kolodyazhnyy Jul 9 '16 at 8:59
  • I've added the crontab using crontab -e my-user so I suppose my script is executed as my-user. In fact, the crontabbed script crashes telling me in the log about a sudo request of password – realtebo Jul 9 '16 at 9:03
  • possible duplicate: askubuntu.com/questions/7477/… there is also the /etc/sudoers – Cloacker Jul 9 '16 at 9:14
  • 2
    I can't see any good reason to do this - if you need to schedule tasks that require elevated privileges to run, then put them in root's crontab (sudo crontab -e) instead of putting them in a user crontab with sudo inside. – steeldriver Jul 9 '16 at 13:11
  • 1
    Agreed with Serg and Steeldriver, although I did run into file ownership problems, e.g. when executing backups from root's crontab with a package not too particular about respecting initial file ownership and rwx mode. -- 1) to create a new user, keep it simple: first sudo adduser my-user then sudo gpasswd -a my-user sudo. Start again from scratch by deleting yr user if necessary. -- 2) to include a new entry with a NOPASSWD tag in sudoers or in a file in /etc/sudoers.d/, make the colon sticks to the tag. E.g. NOPASSWD:. I've not seen it before with interspersed space. – Cbhihe Jul 10 '16 at 9:04
4

Sometimes running a process from root's crontab may cause issues with initial file ownership and rwx mode; those may not be correctly preserved.

In any case:

1) to create a new user, keep it simple:

 $ sudo deluser my-user  # if "my-user" is a regular user
 $ adduser my-user
 $ sudo gpasswd -a my-user sudo

2) to include a new entry with a NOPASSWD tag in sudoers or in a file (e.g. /etc/sudoers.d/60_my-user_rules), make the colon stick to the tag, i.e. NOPASSWD:
I've not seen it before with interspersed space and yr rule becomes:

 my-user my-host = NOPASSWD: /full/path/to/cmd [parameter1 [| parameter2 [| ...]]]

Adding (ALL) before the NOPASSWD: is optional as the rule defaults to (ALL:ALL) anyway. You may however want to not only run your cmd/script with root privilege but also run it as either a given user (spec-user) or as a member of a given group (spec-group) or both. In that case, the rule becomes:

 my-user my-host = ([spec-user][:spec-group]) NOPASSWD: /full/path/to/cmd [parameter1 [| parameter2 [| ...]]]

This will actually restrict yr passwordless sudo disposition to one user, one host and one command. You can harden this rule by specifying the optional parameter(s) to that command. In that case the rule will apply only for that/those exact parameter(s).
For scripts, you could further harden this rule by ensuring that the rule applies only if the script was not modified in any way. This is a way to avoid script-hijacking. This is done through cmd-aliasing and specifying SHA-sums in /etc/sudoers.d/60_my-user_rules.

HTH. Please report if you experience issues with that answer.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.