%sudo ALL=NOPASSWD: ALL seems to have no effect in sudoers

It looks like sudo also ignores the instruction to allow a single account the ability to execute specific commands without supplying the account's password. For example:

bkline localhost = NOPASSWD: /usr/local/bin/do-start-vpn, \
                              /usr/sbin/vpnc-disconnect

This works in any other distribution of Linux. Is this the same bug?

Ok. It tooked us some time in IRC at #ubuntu

In the default sudoers file the final line is the one that starts with %admin
if we uncomment this one (that is almost starting the file)
#%sudo ALL=NOPASSWD: ALL

the rules gets OVERRIDE by this:
%admin ALL=(ALL) ALL

asking for a password, anyway....

So, is not a bug.
BUT, the default sudoers SHOULD be repare to help us, poor wanabes, to avoid this confusion.

You mean originally you added the new rules *after* the general %admin ALL=(ALL) ALL rule? Right, you need to put it before. I'm happy to add a comment to the default sudoers file about this, but let's verify that this was really the reason for the confusion and the right solution.

Actually, no - the sudo rule wasn't added - it's already there at the beginning of the file, commented out by default though.
So, it in fact does come *before* the %admin rule

but doesn't work as *expected*

Yes, the _latest_ entry overrides the former. So the default Gutsy sudoers is very misleading. It first offers you to NOPASSWD sudo group, but if you belong to admin group also, the later entry overrides it, and requires password anyway. This should definitely be changed. Put the %sudo line at the end, that fixes it, for example.

Congrats to Hector and #ubuntu. I just bumbed into this bug, but I would have never understood the reason Clever!

This was put to low, but this is trivial to fix. Just move the configuration line for sudo to the end, or remove the sudo group entirely, and put the suggestions about NOPASSWD to the admin group defnition. So this should be fixed, and the bug marked fixed?

No, it's not fixed until it works the way it's supposed too - rather then expecting the end user to "figure out a hack" and 'fix' it themselves.

This bug was fixed in the package sudo - 1.6.9p12-1ubuntu1

---------------
sudo (1.6.9p12-1ubuntu1) intrepid; urgency=low

  * Merge from debian unstable, remaining changes:
   - debian/rules: Disable lecture, enable tty_tickets by default. (Ubuntu
     specific)
   - Add debian/sudo_root.8: Explanation of root handling through sudo.
     Install it in debian/rules. (Ubuntu specific)
   - sudo.c: If the user successfully authenticated and he is in the 'admin'
     group, then create a stamp ~/.sudo_as_admin_successful. Our default bash
     profile checks for this and displays a short intro about sudo if the
     flag is not present. (Ubuntu specific)
   - env.c: Add "http_proxy" to initial_keepenv_table, so that it is kept
     for "sudo apt-get ...". (Ubuntu specific EBW hack, should disappear at
     some point)
  * logging.c: Ignore SIGPIPE when creating an error email, so that non-fatal
    error messages (like "unable to resolve local host name") do not lead to
    being killed with SIGPIPE if /usr/bin/sendmail does not exist or crashes.
    Forwarded upstream to http://www.gratisoft.us/bugzilla/show_bug.cgi?id=285
    (LP: #32906)
  * env.c: Do not clobber $HOME when not specifying -H or -s. Patch taken from
    upstream CVS. (LP: #221395)
  * debian/postinst: put "NOPASSWD" example at the bottom, so that
    uncommenting it will actually work (later entries override former ones).
    (LP: #131399)

sudo (1.6.9p12-1) unstable; urgency=low

  * new upstream version, closes: #464890

sudo (1.6.9p11-3) unstable; urgency=low

  * patch for configure to fix FTBFS on GNU/kFreeBSD, closes: #465956

sudo (1.6.9p11-2) unstable; urgency=low

  * update version compared in preinst when removing obsolete init.d,
    closes: #459681
  * implement pam session config suggestions from Elizabeth Fong,
    closes: #452457, #402329

sudo (1.6.9p11-1) unstable; urgency=low

  * new upstream version

 -- Martin Pitt <email address hidden> Mon, 05 May 2008 20:31:58 +0200

Any idea when this might be backported to Hardy? I mean geeze; I reported this in Gutsy, watched it thru the Hardy beta's, then 2 weeks after Hardy goes final - it gets fixed *for Intrepid*?

It can only be fixed for fresh installations, not for upgrades. But it still makes sense for 8.04.1.

ah good compromise Martin, at least this way you don't have to touch sudoers on ugrades.

Whoops, I just noticed a typo in the previous upload. Also, since the installer appends the %admin line, we cannot put it at the very bottom. I added a more helpful comment instead.

Hardy SRU prepared, see https://bugs.edge.launchpad.net/ubuntu/hardy/+source/sudo/+bug/221395/comments/4 for the patch.

This bug was fixed in the package sudo - 1.6.9p12-1ubuntu2

---------------
sudo (1.6.9p12-1ubuntu2) intrepid; urgency=low

  * debian/postinst: Fix a typo, and add a more helpful comment about the
    ordering and overriding. (LP: #131399)

 -- Martin Pitt <email address hidden> Wed, 14 May 2008 15:46:24 +0200

Accepted into -proposed, please test and give feedback here

I verified that the fix works correctly

Copied to hardy-updates.

There's still a problem here:

Since the sudo package upgrade won't update the sudoers file, to fix it, one has to execute a command like this:

sudo su -c "mv /etc/sudoers /etc/sudoers.bak && dpkg-reconfigure sudo && sed -i~ s/#\ %/%/ /etc/sudoers && adduser $USER sudo"

This creates a backup and then recreates the sudoers file - so now it's fixed. BUT:

Since the admin line is added by the installer, it will be missing from the fixed file. And on a new installation (Intrepid? 8.04.1?) where the fixed file may be the base, if the installer still adds the admin line after the sudo line, it will again be broken.

Just wanted to point that out - maybe we can find an elegant solution?

(Personally, the way I did it before the sudo group was used in the sudoers file, I simply changed "ALL=(ALL)" to "ALL=NOPASSWD:" on the %admin line. No need for the %sudo line.)

I too just ran into this issue. At the very least have the installer add a comment above the %admin line letting users know if the same user is in the admin group and you want to change some commands to NOPASSWD to add those lines AFTER the %admin line. That should allow people to stop scratching their heads over this issue and wondering what is going on.