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

Bug #131399 reported by Dreadlord_Chris on 2007-08-09
Affects Status Importance Assigned to Milestone
sudo (Ubuntu)
Martin Pitt
Martin Pitt

Bug Description

chris@HAL421:~$ sudo visduo
right after Defaults you find the following 2 lines:
# Uncomment to allow members of group sudo to not need a password

Uncomment the sudo line, save the file, make sure you are in the sudo group:
chris@HAL421:~$ cat /etc/group | grep sudo

log out & back in - sudo anything and you're still asked for a password

chris@HAL421:~$ sudo visduo
add NOPASSWD to the admin line at the bottom:
save, logout/login - sudo now no longer asks for a password

- create a root shell with sudo -i
- mv /etc/sudoers{,.old}
- apt-get install sudo

With the current version, the "# %sudo" line is somewhere in the middle of the newly created /etc/sudoers. With the updated hardy-proposed version, it is at the very bottom.

- mv /etc/sudoers{.old,}

Restore your original sudoers.

Bob Kline (bkline) wrote :

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, \

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

Hector Palacios (hectorpal) wrote :

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)

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.

Martin Pitt (pitti) wrote :

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*

Gatestone (app-iki) wrote :

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!

Martin Pitt (pitti) on 2008-03-27
Changed in sudo:
assignee: nobody → pitti
importance: Undecided → Low
status: New → In Progress
Gatestone (app-iki) wrote :

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.

Launchpad Janitor (janitor) wrote :

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

Changed in sudo:
status: In Progress → Fix Released

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*?

Martin Pitt (pitti) wrote :

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

Changed in sudo:
assignee: nobody → pitti
importance: Undecided → Low
status: New → In Progress
Mike Rosset (mike-rosset) wrote :

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

Martin Pitt (pitti) wrote :

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.

Changed in sudo:
status: Fix Released → Fix Committed
Martin Pitt (pitti) wrote :
description: updated
Launchpad Janitor (janitor) wrote :

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

Changed in sudo:
status: Fix Committed → Fix Released
Steve Langasek (vorlon) wrote :

Accepted into -proposed, please test and give feedback here

Changed in sudo:
status: In Progress → Fix Committed
Sebastien Bacher (seb128) wrote :

I verified that the fix works correctly

Martin Pitt (pitti) wrote :

Copied to hardy-updates.

Changed in sudo:
status: Fix Committed → Fix Released

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

Ethan (ethan-bonick) wrote :

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.