22
~/bin$ cat setbrightness 
id
echo $1 > /sys/class/backlight/intel_backlight/brightness

~/bin$ whoami
rag


~/bin$ sudo -l
Matching Defaults entries for rag on this host:
    env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User rag may run the following commands on this host:
    (root) NOPASSWD: /home/rag/bin/setbrightness
    (ALL : ALL) ALL

EDIT: /etc/sudoers

Defaults    env_reset
Defaults    mail_badpass
Defaults    secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

# Host alias specification

# User alias specification

# Cmnd alias specification
Cmnd_Alias   SETBRIGHTNESS = /home/rag/bin/setbrightness

# User privilege specification
root    ALL=(ALL:ALL) ALL
rag ALL=NOPASSWD:SETBRIGHTNESS

# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL

# See sudoers(5) for more information on "#include" directives:

#includedir /etc/sudoers.d

Run command

~/bin$ sudo /home/rag/bin/setbrightness 3000
[sudo] password for rag:

Can someone please point out why the password is prompted when running sudo for that command?

rag
  • 1,256

2 Answers2

34

It's the order - if I replicate your sudoers file with:

Cmnd_Alias   TESTCOMM = /bin/more
root    ALL=(ALL:ALL) ALL
dave    ALL=NOPASSWD:TESTCOMM
%admin  ALL=(ALL) ALL
%sudo   ALL=(ALL:ALL) ALL

I get the same behaviour e.g. doing sudo more asks for a password, same as sudo .

However...

Cmnd_Alias   TESTCOMM = /bin/more
root    ALL=(ALL:ALL) ALL
%admin  ALL=(ALL) ALL
%sudo   ALL=(ALL:ALL) ALL
dave    ALL=NOPASSWD:TESTCOMM

Let's me use more without a password, just prompting for anything else.

I guess this is due to the order which which things are checked in sudo (bottom-to-top).

Dave C
  • 1,282
  • 9
  • 15
  • yes, it seems to be the problem with order. I do not understand then why the file has this particular order of sections if it is problematic. is it particular to linux mint? the default order is 1. user privelege specification followed by 2. members of group sudo – rag Mar 10 '13 at 18:39
  • My test showing the difference was on Ubuntu 12.10 so it's not specific I think. What I don't know is if this is normal operation or a bug, but I would guess normal operation otherwise it would be being shouted from the rooftops. – Dave C Mar 11 '13 at 11:29
  • later entries override previous ones, so the main sudo config file /etc/sudoers defines some global behaviour (admin group can do it all) and at last includes /etc/sudoers.d/ for custom stuff. if you couldn't override the prev entries then including /etc/sudoers.s/ wouldn't be as useful. the last rule wins, not the more specific one as you might expect. – milan Nov 23 '16 at 12:28
  • @rag The reason that it specifies the user rules before the superuser rules (aka admin/wheel/sudo) is that if you are following the Rule of Least Privilege you should avoid using sudo/root as much as possible. Since sudo has become much more popular than su root a number of distributions are putting the first or sometimes all new users into the admin/wheel/sudo group which is what is causing the confusion. See my answer for a better way to do things. – dragon788 May 22 '17 at 21:23
  • Thank you so much. I browse about 20 different forums, before finding your working solution ♥ – scholi Dec 01 '21 at 21:37
  • NB! Order applies also with /etc/sudoers.d. I added a file which alphabetically came below a NOPASSWD rule, thus overrode the exceptions. Giving the last file a name so it came before work just like it should. – sastorsl Sep 06 '23 at 14:20
4

How did you edit the sudoers file? To verify a valid sudoers file ALWAYS use the visudo command and NEVER edit the sudoers file directly. This looks to be one of those cases.

mdpc
  • 6,834
  • 3
    i edited using visudo. also you can see in sudo -l it displays the configuration as done through visudo – rag Mar 10 '13 at 11:42