On Thu, Jun 17, 2010 at 10:15 AM, Dan McGee <dpmcgee@gmail.com> wrote:
I'm terribly confused still.
$ sudo cat /etc/sudoers Password:
Defaults editor = /usr/bin/vim:/usr/bin/vi
root ALL=(ALL) ALL %wheel ALL=(ALL) ALL dmcgee ALL= NOPASSWD: /usr/sbin/vpnc, /usr/sbin/vpnc-disconnect dmcgee ALL= NOPASSWD: /usr/bin/openconnect
I don't see any exemption for `sudo -l` in there, but it never prompts me for a passwd (even if adding those timeout defaults). Or is it just the presence of any NOPASSWD entry at all? If that is the case, that seems downright silly...
My config is pretty vanilla so try that instead? Since the misbehaviour happened there.
Anyhow,
What if there's a check for sudo's retval like I posted in the comments?
There is no way to tell the difference between the retval of sudo and the retval of the called program as far as I can tell, so this wouldn't quite work.
In the context of falling back to su if sudo pacman fails, it would not matter if the error is due to pacman or to sudo missing permissions for pacman. Notice that it was in direct response to "more password prompts" over "loss of functionality": On Thu, Jun 17, 2010 at 10:00 AM, Allan McRae <allan@archlinux.org> wrote:
I think I have found the issue here. We obviously have a NOPASSWD entry in our sudoers file so "sudo -l" does not require a password.
So the bug is confirmed. However the fix is not fully functional as if I have sudo installed but can not use it for pacman, then I can no longer fall back to using "su -c". I'd choose excess password typing over functionality loss.
In short, su would be the fallback if sudo fails for any reason. Andres P