|
Bugzilla – Full Text Bug Listing |
| Summary: | sudo -nl <command> returns 1 instead of 0 when the command would be allowed | ||
|---|---|---|---|
| Product: | Sudo | Reporter: | Pierre-Olivier Martel <pmartel+sudo> |
| Component: | Sudo | Assignee: | Todd C. Miller <Todd.Miller> |
| Status: | ASSIGNED --- | ||
| Severity: | normal | ||
| Priority: | normal | ||
| Version: | 1.7.10 | ||
| Hardware: | Macintosh | ||
| OS: | MacOS X | ||
| Attachments: | Fix display_cmnd() return value to match sudo 1.8 | ||
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. |
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.