75

I have a NOPASSWD line in /etc/sudoers (edited with visudo)

gatoatigrado    ALL=(ALL) NOPASSWD: /bin/set-slow-cpufreq

However, the output is,

gatoatigrado@coral:~> sudo -n /bin/set-slow-cpufreq
sudo: sorry, a password is required to run sudo

This kind of command works on an OpenSuSE machine, but not on Ubuntu 11.10. What am I doing wrong?

Note: I cannot find any relevant system log messages, e.g. via tail -f /var/log/syslog.

edit

Here is /etc/sudoers.

Defaults    env_reset

# things I've tried copying from an opensuse machine
Defaults always_set_home
Defaults env_keep = "LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS XDG_SESSION_COOKIE"

root    ALL=(ALL:ALL) ALL
gatoatigrado ALL=NOPASSWD: /bin/set-slow-cpufreq
%admin ALL=(ALL) ALL
%sudo   ALL=(ALL:ALL) ALL
  • 2
    Can you show the full sudoers, the order of rules is not irrelevant. – enzotib Jan 31 '12 at 5:49
117

You should put that line after the line with the rule for the sudo group, because, as the sudoers man page states:

   When multiple entries match for a user, they are applied in order.
   Where there are multiple matches, the last match is used (which is not
   necessarily the most specific match).
  • 5
    as an additional note, this applies to users in multiple groups as well: e.g. user is in group admin and group sudo if the rule for sudo is after admin then the rule for sudo overrides the rule for admin for the user in both groups. – Populus Sep 30 '12 at 23:49
  • 2
    Thanks! I added my line to the end of /etc/sudoers and it now works. Full explanation here to people who are interested: techglimpse.com/ubuntu-sudoers-nopasswd-option-not-working – elimisteve Apr 28 '17 at 21:21
4

Ideally if you are customizing what commands can be run via sudo you should be making these changes in a separate file under /etc/sudoers.d/ instead of editing the sudoers file directly. You should also always use visudo to edit the file(s).

Example: sudo visudo -f /etc/sudoers.d/slowcpu

Insert your line granting permission: gatoatigrado ALL=NOPASSWD: /bin/set-slow-cpufreq

Then save and exit and visudo will warn you if you have any syntax errors.

You can run sudo -l to see the permissions that your user has been granted, if any of the user specific NOPASSWD commands appear BEFORE any %groupyouarein ALL=(ALL) ALL command in the output you will be prompted for your password.

If you find yourself creating lots of these sudoers.d files then perhaps you will want to create them named per user so they are easier to visualize. Keep in mind that the ordering of the FILE NAMES and of the RULES within the file is very important, the LAST one loaded wins, whether it is MORE or LESS permissive than the previous entries.

You can control the file name ordering by using a prefix of 00-99 or aa/bb/cc, though also keep in mind that if you have ANY files that don't have numeric prefix, they will load after the numbered files, overriding the settings. This is because depending on your language settings the "lexical sorting" the shell uses sorts numbers first and then may interleave upper and lowercase when sorting in "ascending" order.

Try running printf '%s\n' {{0..99},{A-Z},{a-z}} | sort and printf '%s\n' {{0..99},{A-Z},{a-z}} | LANG=C sort to see whether your current language prints AaBbCc etc or ABC then abc to determine what the best "last" letter prefix to use would be.

  • I agree with this. Some of the logic in editing the /etc/sudoers file seemed counter intuitive - I could not get %wheel ALL=(ALL) NOPASSWD: ALL to work the way it was written in sudoers until I read a post where someone said the #includedir /etc/sudoers.d line had to be before the other lines like %SUDO and %WHEEL. When I put the #include dir above the other group permissions, they started working. So then I made files for each group in /etc/sudoers.d/ numbered in the same order they were in the sudoers file, but root ALL=(ALL) ALL had to still be sudoers below the #includedir line. Weird. – AveryFreeman Nov 27 '17 at 14:41
  • Actually I think the includedir should remain at the end of sudoers. What you were probably seeing is one of the other files in your sudoers.d was undoing your change. You may have also had a line further down in your main file that was restricting the wheel group. Keep in mind that sudoers is processed where the last rule to apply to a command or group wins so being more specific helps but if a general ANY command comes at the end and doesn't have NOPASSWD it will override your previous exceptions. This is why you should have your rules in separate files so they are processed later. – dragon788 Nov 27 '17 at 15:18
  • I don't think so, it was a brand new install of arch. All I did was try and uncomment that one line. But that's definitely a good thing to check for, thanks. – AveryFreeman Nov 27 '17 at 15:33
  • Some systems don't actually use wheel and instead use a group called sudo or adm or admin. I can't recall the Arch behavior but you can run id and see which groups you belong to. – dragon788 Nov 27 '17 at 16:14
  • Arch uses wheel. – AveryFreeman Nov 27 '17 at 21:38
4

Just ran into this too.

My situation is I'm setting up a remote system that will run headless. I have enabled full disk encryption (otherwise an attacker with physicall access can do anything he or she wants) I want to auth with pub key only (I will unset the password so that the "have something, know something" scheme will be a password protected keypair --root login is of course disabled entirely)

The Ubuntu installer prompts for a non-root admin user which gets added to the group sudo. I had then manually added myself to the sudoers file using sudo visudo:

my_username ALL=(ALL:ALL) NOPASSWD:ALL

NOTE if you use nopasswd on your laptop you must always lock your computer as you walk away or else a casual attacker can compromise a lot while you're getting up to put cream in your coffee

I was still having to password authenticate.

enzotib's answer is the key to what's going on. The group sudo shows up in sudoers after the entry for my username.

Rather than moving my entry below the sudo line I simply removed the line I had previously added and then added NOPASSWD to the entry for %sudo

That seems to work. Again only use nopasswd if you really need it (In my case it was precisely what I needed, for most users requiring a password for sudo activity is best)

Additional WARNING: Always edit sudoers with visudo. (sudo visudo) Also, having another window open switched to the root user allows you to recover any mistakes you might make while changing the sudoers file.

  • It is never a good idea to enable NOPASSWD against any/all commands, this means that anybody that gets on your system and manages to get a user into the sudo group will be able to do ANYTHING BAD to your system VERY quickly. I can easily do this with only a few minutes of access using a LiveCD or by tricking your user into running a cmd called sudo that uses your own permissions to add another user to the sudo group in addition to running your requested command. – dragon788 May 22 '17 at 20:05
  • 2
    Don't make blanket statements like this. On a headless system it's not desirable to set a login password at all (relying on keypairs instead) I have enabled full disk encryption so good luck with that live cd. (which by the way would allow you to do all sorts of fun things on an unencrypted system regardless of the sudoers file) Also you can't write to any of the locations in my PATH and I'm not giving you shell to begin with unless I trust you not to attempt to subvert the system. Your security concern is not invalid, it's simply outdated and not as universally applicable as you imply. – jorfus May 29 '17 at 21:06
  • For those that don't have a deep understanding of security like you, this kind of recommendation is probably better than the alternative but I agree it's not ideal. – dragon788 May 29 '17 at 21:48
  • @dragon788 True enough, maybe we can both edit our responses to help users of all levels take a step towards better security. I'll add a warning to enable full disk encryption to prevent compromise when an attacker has physical access and a note that if a laptop user forgets to lock his or her computer in public, sudo nopasswd could lead to quick compromise. (Though I would propose setting a five minute lock and screen lock quick key could actually lead to better security.) – jorfus Jun 3 '17 at 18:50
  • Excellent update, my answer doesn't have any strong recommendations other than these comments here, and ironically enough at work where I do use full disk encryption I've ended up enabling NOPASSWD because I have a very secure password that becomes a pain to type repeatedly, and I use xautolock to lock my machine after a short idle time. – dragon788 Jun 16 '17 at 15:29
0

On the remote system, drop the encryption, but let everything be owned by a root as in the group of "Administrators" - that is not 0!
You can amend #sudo -g Administrators to those that need full access - not in the sudo file, but .login profile. Any standard script now can have access to the remote as "root" and you can protect the files that must be protected.
Another handy "group" is "Sandbox" with a login directory in the browser cache and can read this freely and nothing else. Use upper case first character.

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.