Bugzilla – Bug 590
sudo -nl <command> returns 1 instead of 0 when the command would be allowed
Last modified: 2013-02-25 18:32:59 MST
You can use the -nl <command> combination to determine whether you would be able to run a command without authenticating. On 1.7.10, sudo returns 1 for a command that would normally be accepted without authenticating. Steps: - Edit sudoers to allow executing of /bin/ls for my user without a password - Run: $> sudo -nl /bin/ls $> echo $? 1 This works as expected on 1.7.9p1 It looks like this part of the diff is what changed the behavior: - /* Deferred exit due to sudo_ldap_close() */ - if (ISSET(sudo_mode, (MODE_VALIDATE|MODE_CHECK|MODE_LIST))) { - if (list_pw != NULL) - pw_delref(list_pw); - exit(rc); - } - + if (ISSET(sudo_mode, (MODE_VALIDATE|MODE_CHECK|MODE_LIST))) { + /* rval already set appropriately */ + goto done; + } In combination with: +done: + cleanup(0); + exit(!rval); Here, rval will be 0 in case of success, so you will exit with non-0. This is a problem for scripts that check whether they will be able to perform a given task or not depending on the configuration.
Those changes were merged from the sudo 1.8 branch. The problem is caused by differences in the return value of the display_cmnd() function.
Created attachment 362 [details] Fix display_cmnd() return value to match sudo 1.8
Is there a new update planned soon?
Todd, this does not seem to fix the problem. I applied your patch on top of 1.7.10p6 and now -nl always returns 0, even if the command is not in my sudoers.
It has never been the case that you can use the -nl flags to determine whether a command can be run without prompting for a password. The rules for getting a list of what commands may be run is looser than what is required. See the "listpw" setting in the sudoers manual for more information. Here's what I see with sudo 1.7.10p7 which has the patch applied: $ sudo-1.7.10p7 -l User millert may run the following commands on this host: (ALL) /usr/bin/, (ALL) NOPASSWD: /bin/ls $ sudo-1.7.10p7 -knl ls ; echo $? /bin/ls 0 $ sudo-1.7.10p7 -knl who ; echo $? /usr/bin/who 0 $ sudo-1.7.10p7 -knl nothing ; echo $? sudo-1.7.10p7: nothing: command not found 1 $ sudo-1.7.10p7 -knl ping ; echo $? 1 On this system /bin and /usr/bin are not the same. While I agree that it would make sense for "sudo -nl" to prompt for a password if the command would need one to be run, that's not how sudo has behaved in the past. I think if you check the behavior of sudo 1.7.9p1 you'll see the same thing.
Here is what I have in my sudoers: %admin ALL=(ALL) ALL user ALL=(ALL) NOPASSWD:/bin/ls - On the 1.7.4p6 that you can find on Mountain Lion: $> sudo -knl ls; echo %? /bin/ls 0 $> sudo -knl rm; echo $? sudo: sorry, a password is required to run sudo 1 - Now, on the 1.7.10p6 WITHOUT your patch applied: $> sudo -knl ls; echo $? /bin/ls 1 $> sudo -knl rm; echo $? /bin/rm 1 - Finally, on 1.7.10p6 WITH your patch applied: $> sudo -knl ls; echo $? /bin/ls 0 $> sudo -knl rm; echo $? /bin/rm 0 Yet, if I were to run “sudo rm something”, it would ask for a password. From the manpage, it seems that the point of -nl is just that: -l […] If command is specified but not allowed, sudo will exit with a status value of 1. […] -n […] prevents sudo from prompting the user for a password. If a password is required for the command to run, sudo will display an error messages and exit.
The behavior is actually a bug in that version of sudo that inadvertently caused "sudo -l command" to use the same code path as when actually executing a command, but only when the -n flag was set. I will consider changing the behavior in a non-buggy way.
So, what is the point of the -l option then? I am not sure I follow.