Why does my setup for no password prompt in /etc/sudoers not work? [duplicate]

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
1
down vote

favorite













This question already has an answer here:



  • Why NOPASSWD in visudo on Linux Mint 18 does not work

    3 answers



My sudo version is



$ sudo --version
Sudo version 1.8.16
Sudoers policy plugin version 1.8.16
Sudoers file grammar version 45
Sudoers I/O plugin version 1.8.16

$ which sudo
/usr/bin/sudo

$ whereis sudo
sudo: /usr/bin/sudo /usr/lib/sudo /usr/share/man/man8/sudo.8.gz


I added a line to /etc/sudoers following the line for root:



# User privilege specification
root ALL=(ALL:ALL) ALL
# my change for scaling down cpu freq
t ALL=(ALL) NOPASSWD: /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh


But after I reboot Ubuntu 16.04, I still need to provide password when running the script with sudo:



$ sudo /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh 1600000
[sudo] password for t:


I was wondering why?



Note that in /etc/sudoers,



  • I notice that the separator between root and ALL is a tab, and I also separate t and ALL with a tab, and the other separators are spaces. Originally I separated t and ALL with a few spaces, which didn't work. Does what the separator is matter?


  • /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh is pathname without any symlink, and originally, I tried a symlink, which didn't work. Does a symlink matter or not?


Thanks.




Update:



As the reply by steve suggested, I changed the line in /etc/sudoers to be



t ALL=(ALL) NOPASSWD: /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh *


by adding * at the end, but it doesn't work.



Currently my /etc/sudoers looks like



#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults env_reset
Defaults mail_badpass
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root ALL=(ALL:ALL) ALL
# my change for scaling down cpu freq
# t ALL=(ALL:ALL) NOPASSWD: /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh *
t ALL=(ALL:ALL) NOPASSWD: /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh *

# 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


The groups of t include adm (is adm same as admin?) and sudo:



$ groups t
t : t adm cdrom sudo dip plugdev lpadmin sambashare


The commands allowed to be run by t are:



$ sudo -l
Matching Defaults entries for t on ocean:
env_reset, mail_badpass,
secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin

User t may run the following commands on ocean:
(ALL : ALL) NOPASSWD:
/home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh *
(ALL : ALL) ALL






share|improve this question














marked as duplicate by muru, G-Man, Christopher, Isaac, Wouter Verhelst Apr 3 at 11:33


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.














  • does user t belong to the sudo or the admin group?
    – Rui F Ribeiro
    Apr 1 at 21:40











  • just for clarity, could you also post the output of sudo -l when logged in as user "t" ?
    – steve
    Apr 1 at 21:42










  • @Rui Updated. Is adm same asadmin group?
    – Tim
    Apr 1 at 21:54






  • 1




    @steve: updated. indeed the script is listed.
    – Tim
    Apr 1 at 21:54






  • 1




    @Tim: No, admin and adm are not the same. You can tell because one of them has an in in it.
    – jwodder
    Apr 1 at 22:27














up vote
1
down vote

favorite













This question already has an answer here:



  • Why NOPASSWD in visudo on Linux Mint 18 does not work

    3 answers



My sudo version is



$ sudo --version
Sudo version 1.8.16
Sudoers policy plugin version 1.8.16
Sudoers file grammar version 45
Sudoers I/O plugin version 1.8.16

$ which sudo
/usr/bin/sudo

$ whereis sudo
sudo: /usr/bin/sudo /usr/lib/sudo /usr/share/man/man8/sudo.8.gz


I added a line to /etc/sudoers following the line for root:



# User privilege specification
root ALL=(ALL:ALL) ALL
# my change for scaling down cpu freq
t ALL=(ALL) NOPASSWD: /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh


But after I reboot Ubuntu 16.04, I still need to provide password when running the script with sudo:



$ sudo /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh 1600000
[sudo] password for t:


I was wondering why?



Note that in /etc/sudoers,



  • I notice that the separator between root and ALL is a tab, and I also separate t and ALL with a tab, and the other separators are spaces. Originally I separated t and ALL with a few spaces, which didn't work. Does what the separator is matter?


  • /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh is pathname without any symlink, and originally, I tried a symlink, which didn't work. Does a symlink matter or not?


Thanks.




Update:



As the reply by steve suggested, I changed the line in /etc/sudoers to be



t ALL=(ALL) NOPASSWD: /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh *


by adding * at the end, but it doesn't work.



Currently my /etc/sudoers looks like



#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults env_reset
Defaults mail_badpass
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root ALL=(ALL:ALL) ALL
# my change for scaling down cpu freq
# t ALL=(ALL:ALL) NOPASSWD: /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh *
t ALL=(ALL:ALL) NOPASSWD: /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh *

# 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


The groups of t include adm (is adm same as admin?) and sudo:



$ groups t
t : t adm cdrom sudo dip plugdev lpadmin sambashare


The commands allowed to be run by t are:



$ sudo -l
Matching Defaults entries for t on ocean:
env_reset, mail_badpass,
secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin

User t may run the following commands on ocean:
(ALL : ALL) NOPASSWD:
/home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh *
(ALL : ALL) ALL






share|improve this question














marked as duplicate by muru, G-Man, Christopher, Isaac, Wouter Verhelst Apr 3 at 11:33


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.














  • does user t belong to the sudo or the admin group?
    – Rui F Ribeiro
    Apr 1 at 21:40











  • just for clarity, could you also post the output of sudo -l when logged in as user "t" ?
    – steve
    Apr 1 at 21:42










  • @Rui Updated. Is adm same asadmin group?
    – Tim
    Apr 1 at 21:54






  • 1




    @steve: updated. indeed the script is listed.
    – Tim
    Apr 1 at 21:54






  • 1




    @Tim: No, admin and adm are not the same. You can tell because one of them has an in in it.
    – jwodder
    Apr 1 at 22:27












up vote
1
down vote

favorite









up vote
1
down vote

favorite












This question already has an answer here:



  • Why NOPASSWD in visudo on Linux Mint 18 does not work

    3 answers



My sudo version is



$ sudo --version
Sudo version 1.8.16
Sudoers policy plugin version 1.8.16
Sudoers file grammar version 45
Sudoers I/O plugin version 1.8.16

$ which sudo
/usr/bin/sudo

$ whereis sudo
sudo: /usr/bin/sudo /usr/lib/sudo /usr/share/man/man8/sudo.8.gz


I added a line to /etc/sudoers following the line for root:



# User privilege specification
root ALL=(ALL:ALL) ALL
# my change for scaling down cpu freq
t ALL=(ALL) NOPASSWD: /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh


But after I reboot Ubuntu 16.04, I still need to provide password when running the script with sudo:



$ sudo /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh 1600000
[sudo] password for t:


I was wondering why?



Note that in /etc/sudoers,



  • I notice that the separator between root and ALL is a tab, and I also separate t and ALL with a tab, and the other separators are spaces. Originally I separated t and ALL with a few spaces, which didn't work. Does what the separator is matter?


  • /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh is pathname without any symlink, and originally, I tried a symlink, which didn't work. Does a symlink matter or not?


Thanks.




Update:



As the reply by steve suggested, I changed the line in /etc/sudoers to be



t ALL=(ALL) NOPASSWD: /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh *


by adding * at the end, but it doesn't work.



Currently my /etc/sudoers looks like



#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults env_reset
Defaults mail_badpass
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root ALL=(ALL:ALL) ALL
# my change for scaling down cpu freq
# t ALL=(ALL:ALL) NOPASSWD: /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh *
t ALL=(ALL:ALL) NOPASSWD: /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh *

# 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


The groups of t include adm (is adm same as admin?) and sudo:



$ groups t
t : t adm cdrom sudo dip plugdev lpadmin sambashare


The commands allowed to be run by t are:



$ sudo -l
Matching Defaults entries for t on ocean:
env_reset, mail_badpass,
secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin

User t may run the following commands on ocean:
(ALL : ALL) NOPASSWD:
/home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh *
(ALL : ALL) ALL






share|improve this question















This question already has an answer here:



  • Why NOPASSWD in visudo on Linux Mint 18 does not work

    3 answers



My sudo version is



$ sudo --version
Sudo version 1.8.16
Sudoers policy plugin version 1.8.16
Sudoers file grammar version 45
Sudoers I/O plugin version 1.8.16

$ which sudo
/usr/bin/sudo

$ whereis sudo
sudo: /usr/bin/sudo /usr/lib/sudo /usr/share/man/man8/sudo.8.gz


I added a line to /etc/sudoers following the line for root:



# User privilege specification
root ALL=(ALL:ALL) ALL
# my change for scaling down cpu freq
t ALL=(ALL) NOPASSWD: /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh


But after I reboot Ubuntu 16.04, I still need to provide password when running the script with sudo:



$ sudo /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh 1600000
[sudo] password for t:


I was wondering why?



Note that in /etc/sudoers,



  • I notice that the separator between root and ALL is a tab, and I also separate t and ALL with a tab, and the other separators are spaces. Originally I separated t and ALL with a few spaces, which didn't work. Does what the separator is matter?


  • /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh is pathname without any symlink, and originally, I tried a symlink, which didn't work. Does a symlink matter or not?


Thanks.




Update:



As the reply by steve suggested, I changed the line in /etc/sudoers to be



t ALL=(ALL) NOPASSWD: /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh *


by adding * at the end, but it doesn't work.



Currently my /etc/sudoers looks like



#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults env_reset
Defaults mail_badpass
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root ALL=(ALL:ALL) ALL
# my change for scaling down cpu freq
# t ALL=(ALL:ALL) NOPASSWD: /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh *
t ALL=(ALL:ALL) NOPASSWD: /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh *

# 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


The groups of t include adm (is adm same as admin?) and sudo:



$ groups t
t : t adm cdrom sudo dip plugdev lpadmin sambashare


The commands allowed to be run by t are:



$ sudo -l
Matching Defaults entries for t on ocean:
env_reset, mail_badpass,
secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin

User t may run the following commands on ocean:
(ALL : ALL) NOPASSWD:
/home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh *
(ALL : ALL) ALL




This question already has an answer here:



  • Why NOPASSWD in visudo on Linux Mint 18 does not work

    3 answers









share|improve this question













share|improve this question




share|improve this question








edited Apr 1 at 21:53

























asked Apr 1 at 19:50









Tim

22.6k63224401




22.6k63224401




marked as duplicate by muru, G-Man, Christopher, Isaac, Wouter Verhelst Apr 3 at 11:33


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.






marked as duplicate by muru, G-Man, Christopher, Isaac, Wouter Verhelst Apr 3 at 11:33


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.













  • does user t belong to the sudo or the admin group?
    – Rui F Ribeiro
    Apr 1 at 21:40











  • just for clarity, could you also post the output of sudo -l when logged in as user "t" ?
    – steve
    Apr 1 at 21:42










  • @Rui Updated. Is adm same asadmin group?
    – Tim
    Apr 1 at 21:54






  • 1




    @steve: updated. indeed the script is listed.
    – Tim
    Apr 1 at 21:54






  • 1




    @Tim: No, admin and adm are not the same. You can tell because one of them has an in in it.
    – jwodder
    Apr 1 at 22:27
















  • does user t belong to the sudo or the admin group?
    – Rui F Ribeiro
    Apr 1 at 21:40











  • just for clarity, could you also post the output of sudo -l when logged in as user "t" ?
    – steve
    Apr 1 at 21:42










  • @Rui Updated. Is adm same asadmin group?
    – Tim
    Apr 1 at 21:54






  • 1




    @steve: updated. indeed the script is listed.
    – Tim
    Apr 1 at 21:54






  • 1




    @Tim: No, admin and adm are not the same. You can tell because one of them has an in in it.
    – jwodder
    Apr 1 at 22:27















does user t belong to the sudo or the admin group?
– Rui F Ribeiro
Apr 1 at 21:40





does user t belong to the sudo or the admin group?
– Rui F Ribeiro
Apr 1 at 21:40













just for clarity, could you also post the output of sudo -l when logged in as user "t" ?
– steve
Apr 1 at 21:42




just for clarity, could you also post the output of sudo -l when logged in as user "t" ?
– steve
Apr 1 at 21:42












@Rui Updated. Is adm same asadmin group?
– Tim
Apr 1 at 21:54




@Rui Updated. Is adm same asadmin group?
– Tim
Apr 1 at 21:54




1




1




@steve: updated. indeed the script is listed.
– Tim
Apr 1 at 21:54




@steve: updated. indeed the script is listed.
– Tim
Apr 1 at 21:54




1




1




@Tim: No, admin and adm are not the same. You can tell because one of them has an in in it.
– jwodder
Apr 1 at 22:27




@Tim: No, admin and adm are not the same. You can tell because one of them has an in in it.
– jwodder
Apr 1 at 22:27










2 Answers
2






active

oldest

votes

















up vote
2
down vote



accepted










Besides the argument, as @steve mentions, change the ALL=(ALL) for ALL=(ALL:ALL) as:



t ALL=(ALL:ALL) NOPASSWD: /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh *


If the user t belongs to the sudo or admin group, you also have to put that line after the generic rules for the admin and sudo group. Per man sudoers, the last line contemplating a condition wins:




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).




Thus, if the more restrictive conditions are met on your now last line, the NOPASSWD directive will be applied, and then the password won't be asked anymore.






share|improve this answer






















  • Thanks. It doesn't work. Does (ALL:ALL) mean all terminals and all target users, right?
    – Tim
    Apr 1 at 21:28











  • see ubuntuforums.org/showthread.php?t=1918842
    – Rui F Ribeiro
    Apr 1 at 21:34






  • 1




    Thanks. Moving the new line to the end of the file works.
    – Tim
    Apr 1 at 21:58










  • Is adm the same group as admin?
    – Tim
    Apr 1 at 22:09







  • 1




    I think you are overlooking the NOPASSWD directive
    – Rui F Ribeiro
    Apr 1 at 22:55

















up vote
3
down vote













Perhaps the fact you're passing an argument is causing the issue.



Instead of:



t ALL=(ALL) NOPASSWD: /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh


try this:



t ALL=(ALL) NOPASSWD: /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh *





share|improve this answer




















  • I could swear newer versions of sudo require the latter syntax.
    – Rui F Ribeiro
    Apr 1 at 20:39










  • Thanks. In /etc/sudoers, does using a pathname containing symlink(s) matter? Furthermore, when running the command via its symlink path with sudo, would there still be password prompt if the symlink is searched in the invoking user's PATH, e.g. sudo -E env "PATH=$PATH" changeCpuFreq.sh 1600000?
    – Tim
    Apr 1 at 20:57











  • Also adding * doesn't work. See my update. I also added my sudo version.
    – Tim
    Apr 1 at 21:13











  • Thanks. After moving the new line to the end of /etc/sudoers, it works both with and without *.
    – Tim
    Apr 1 at 23:55











  • @Rui: Could you elaborate "newer versions of sudo require the latter syntax"? My Sudo version is 1.8.16, and after moving the new line to the end of /etc/sudoers, it works both with and without *.
    – Tim
    Apr 2 at 12:01


















2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
2
down vote



accepted










Besides the argument, as @steve mentions, change the ALL=(ALL) for ALL=(ALL:ALL) as:



t ALL=(ALL:ALL) NOPASSWD: /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh *


If the user t belongs to the sudo or admin group, you also have to put that line after the generic rules for the admin and sudo group. Per man sudoers, the last line contemplating a condition wins:




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).




Thus, if the more restrictive conditions are met on your now last line, the NOPASSWD directive will be applied, and then the password won't be asked anymore.






share|improve this answer






















  • Thanks. It doesn't work. Does (ALL:ALL) mean all terminals and all target users, right?
    – Tim
    Apr 1 at 21:28











  • see ubuntuforums.org/showthread.php?t=1918842
    – Rui F Ribeiro
    Apr 1 at 21:34






  • 1




    Thanks. Moving the new line to the end of the file works.
    – Tim
    Apr 1 at 21:58










  • Is adm the same group as admin?
    – Tim
    Apr 1 at 22:09







  • 1




    I think you are overlooking the NOPASSWD directive
    – Rui F Ribeiro
    Apr 1 at 22:55














up vote
2
down vote



accepted










Besides the argument, as @steve mentions, change the ALL=(ALL) for ALL=(ALL:ALL) as:



t ALL=(ALL:ALL) NOPASSWD: /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh *


If the user t belongs to the sudo or admin group, you also have to put that line after the generic rules for the admin and sudo group. Per man sudoers, the last line contemplating a condition wins:




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).




Thus, if the more restrictive conditions are met on your now last line, the NOPASSWD directive will be applied, and then the password won't be asked anymore.






share|improve this answer






















  • Thanks. It doesn't work. Does (ALL:ALL) mean all terminals and all target users, right?
    – Tim
    Apr 1 at 21:28











  • see ubuntuforums.org/showthread.php?t=1918842
    – Rui F Ribeiro
    Apr 1 at 21:34






  • 1




    Thanks. Moving the new line to the end of the file works.
    – Tim
    Apr 1 at 21:58










  • Is adm the same group as admin?
    – Tim
    Apr 1 at 22:09







  • 1




    I think you are overlooking the NOPASSWD directive
    – Rui F Ribeiro
    Apr 1 at 22:55












up vote
2
down vote



accepted







up vote
2
down vote



accepted






Besides the argument, as @steve mentions, change the ALL=(ALL) for ALL=(ALL:ALL) as:



t ALL=(ALL:ALL) NOPASSWD: /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh *


If the user t belongs to the sudo or admin group, you also have to put that line after the generic rules for the admin and sudo group. Per man sudoers, the last line contemplating a condition wins:




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).




Thus, if the more restrictive conditions are met on your now last line, the NOPASSWD directive will be applied, and then the password won't be asked anymore.






share|improve this answer














Besides the argument, as @steve mentions, change the ALL=(ALL) for ALL=(ALL:ALL) as:



t ALL=(ALL:ALL) NOPASSWD: /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh *


If the user t belongs to the sudo or admin group, you also have to put that line after the generic rules for the admin and sudo group. Per man sudoers, the last line contemplating a condition wins:




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).




Thus, if the more restrictive conditions are met on your now last line, the NOPASSWD directive will be applied, and then the password won't be asked anymore.







share|improve this answer














share|improve this answer



share|improve this answer








edited Apr 4 at 3:04

























answered Apr 1 at 21:23









Rui F Ribeiro

34.7k1269113




34.7k1269113











  • Thanks. It doesn't work. Does (ALL:ALL) mean all terminals and all target users, right?
    – Tim
    Apr 1 at 21:28











  • see ubuntuforums.org/showthread.php?t=1918842
    – Rui F Ribeiro
    Apr 1 at 21:34






  • 1




    Thanks. Moving the new line to the end of the file works.
    – Tim
    Apr 1 at 21:58










  • Is adm the same group as admin?
    – Tim
    Apr 1 at 22:09







  • 1




    I think you are overlooking the NOPASSWD directive
    – Rui F Ribeiro
    Apr 1 at 22:55
















  • Thanks. It doesn't work. Does (ALL:ALL) mean all terminals and all target users, right?
    – Tim
    Apr 1 at 21:28











  • see ubuntuforums.org/showthread.php?t=1918842
    – Rui F Ribeiro
    Apr 1 at 21:34






  • 1




    Thanks. Moving the new line to the end of the file works.
    – Tim
    Apr 1 at 21:58










  • Is adm the same group as admin?
    – Tim
    Apr 1 at 22:09







  • 1




    I think you are overlooking the NOPASSWD directive
    – Rui F Ribeiro
    Apr 1 at 22:55















Thanks. It doesn't work. Does (ALL:ALL) mean all terminals and all target users, right?
– Tim
Apr 1 at 21:28





Thanks. It doesn't work. Does (ALL:ALL) mean all terminals and all target users, right?
– Tim
Apr 1 at 21:28













see ubuntuforums.org/showthread.php?t=1918842
– Rui F Ribeiro
Apr 1 at 21:34




see ubuntuforums.org/showthread.php?t=1918842
– Rui F Ribeiro
Apr 1 at 21:34




1




1




Thanks. Moving the new line to the end of the file works.
– Tim
Apr 1 at 21:58




Thanks. Moving the new line to the end of the file works.
– Tim
Apr 1 at 21:58












Is adm the same group as admin?
– Tim
Apr 1 at 22:09





Is adm the same group as admin?
– Tim
Apr 1 at 22:09





1




1




I think you are overlooking the NOPASSWD directive
– Rui F Ribeiro
Apr 1 at 22:55




I think you are overlooking the NOPASSWD directive
– Rui F Ribeiro
Apr 1 at 22:55












up vote
3
down vote













Perhaps the fact you're passing an argument is causing the issue.



Instead of:



t ALL=(ALL) NOPASSWD: /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh


try this:



t ALL=(ALL) NOPASSWD: /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh *





share|improve this answer




















  • I could swear newer versions of sudo require the latter syntax.
    – Rui F Ribeiro
    Apr 1 at 20:39










  • Thanks. In /etc/sudoers, does using a pathname containing symlink(s) matter? Furthermore, when running the command via its symlink path with sudo, would there still be password prompt if the symlink is searched in the invoking user's PATH, e.g. sudo -E env "PATH=$PATH" changeCpuFreq.sh 1600000?
    – Tim
    Apr 1 at 20:57











  • Also adding * doesn't work. See my update. I also added my sudo version.
    – Tim
    Apr 1 at 21:13











  • Thanks. After moving the new line to the end of /etc/sudoers, it works both with and without *.
    – Tim
    Apr 1 at 23:55











  • @Rui: Could you elaborate "newer versions of sudo require the latter syntax"? My Sudo version is 1.8.16, and after moving the new line to the end of /etc/sudoers, it works both with and without *.
    – Tim
    Apr 2 at 12:01















up vote
3
down vote













Perhaps the fact you're passing an argument is causing the issue.



Instead of:



t ALL=(ALL) NOPASSWD: /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh


try this:



t ALL=(ALL) NOPASSWD: /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh *





share|improve this answer




















  • I could swear newer versions of sudo require the latter syntax.
    – Rui F Ribeiro
    Apr 1 at 20:39










  • Thanks. In /etc/sudoers, does using a pathname containing symlink(s) matter? Furthermore, when running the command via its symlink path with sudo, would there still be password prompt if the symlink is searched in the invoking user's PATH, e.g. sudo -E env "PATH=$PATH" changeCpuFreq.sh 1600000?
    – Tim
    Apr 1 at 20:57











  • Also adding * doesn't work. See my update. I also added my sudo version.
    – Tim
    Apr 1 at 21:13











  • Thanks. After moving the new line to the end of /etc/sudoers, it works both with and without *.
    – Tim
    Apr 1 at 23:55











  • @Rui: Could you elaborate "newer versions of sudo require the latter syntax"? My Sudo version is 1.8.16, and after moving the new line to the end of /etc/sudoers, it works both with and without *.
    – Tim
    Apr 2 at 12:01













up vote
3
down vote










up vote
3
down vote









Perhaps the fact you're passing an argument is causing the issue.



Instead of:



t ALL=(ALL) NOPASSWD: /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh


try this:



t ALL=(ALL) NOPASSWD: /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh *





share|improve this answer












Perhaps the fact you're passing an argument is causing the issue.



Instead of:



t ALL=(ALL) NOPASSWD: /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh


try this:



t ALL=(ALL) NOPASSWD: /home/t/program_files/hardware/cpu/cpuFreq/changeCpuFreq.sh *






share|improve this answer












share|improve this answer



share|improve this answer










answered Apr 1 at 20:20









steve

12.3k22048




12.3k22048











  • I could swear newer versions of sudo require the latter syntax.
    – Rui F Ribeiro
    Apr 1 at 20:39










  • Thanks. In /etc/sudoers, does using a pathname containing symlink(s) matter? Furthermore, when running the command via its symlink path with sudo, would there still be password prompt if the symlink is searched in the invoking user's PATH, e.g. sudo -E env "PATH=$PATH" changeCpuFreq.sh 1600000?
    – Tim
    Apr 1 at 20:57











  • Also adding * doesn't work. See my update. I also added my sudo version.
    – Tim
    Apr 1 at 21:13











  • Thanks. After moving the new line to the end of /etc/sudoers, it works both with and without *.
    – Tim
    Apr 1 at 23:55











  • @Rui: Could you elaborate "newer versions of sudo require the latter syntax"? My Sudo version is 1.8.16, and after moving the new line to the end of /etc/sudoers, it works both with and without *.
    – Tim
    Apr 2 at 12:01

















  • I could swear newer versions of sudo require the latter syntax.
    – Rui F Ribeiro
    Apr 1 at 20:39










  • Thanks. In /etc/sudoers, does using a pathname containing symlink(s) matter? Furthermore, when running the command via its symlink path with sudo, would there still be password prompt if the symlink is searched in the invoking user's PATH, e.g. sudo -E env "PATH=$PATH" changeCpuFreq.sh 1600000?
    – Tim
    Apr 1 at 20:57











  • Also adding * doesn't work. See my update. I also added my sudo version.
    – Tim
    Apr 1 at 21:13











  • Thanks. After moving the new line to the end of /etc/sudoers, it works both with and without *.
    – Tim
    Apr 1 at 23:55











  • @Rui: Could you elaborate "newer versions of sudo require the latter syntax"? My Sudo version is 1.8.16, and after moving the new line to the end of /etc/sudoers, it works both with and without *.
    – Tim
    Apr 2 at 12:01
















I could swear newer versions of sudo require the latter syntax.
– Rui F Ribeiro
Apr 1 at 20:39




I could swear newer versions of sudo require the latter syntax.
– Rui F Ribeiro
Apr 1 at 20:39












Thanks. In /etc/sudoers, does using a pathname containing symlink(s) matter? Furthermore, when running the command via its symlink path with sudo, would there still be password prompt if the symlink is searched in the invoking user's PATH, e.g. sudo -E env "PATH=$PATH" changeCpuFreq.sh 1600000?
– Tim
Apr 1 at 20:57





Thanks. In /etc/sudoers, does using a pathname containing symlink(s) matter? Furthermore, when running the command via its symlink path with sudo, would there still be password prompt if the symlink is searched in the invoking user's PATH, e.g. sudo -E env "PATH=$PATH" changeCpuFreq.sh 1600000?
– Tim
Apr 1 at 20:57













Also adding * doesn't work. See my update. I also added my sudo version.
– Tim
Apr 1 at 21:13





Also adding * doesn't work. See my update. I also added my sudo version.
– Tim
Apr 1 at 21:13













Thanks. After moving the new line to the end of /etc/sudoers, it works both with and without *.
– Tim
Apr 1 at 23:55





Thanks. After moving the new line to the end of /etc/sudoers, it works both with and without *.
– Tim
Apr 1 at 23:55













@Rui: Could you elaborate "newer versions of sudo require the latter syntax"? My Sudo version is 1.8.16, and after moving the new line to the end of /etc/sudoers, it works both with and without *.
– Tim
Apr 2 at 12:01





@Rui: Could you elaborate "newer versions of sudo require the latter syntax"? My Sudo version is 1.8.16, and after moving the new line to the end of /etc/sudoers, it works both with and without *.
– Tim
Apr 2 at 12:01



Popular posts from this blog

How to check contact read email or not when send email to Individual?

Bahrain

Postfix configuration issue with fips on centos 7; mailgun relay