sudo hangs before password

I'd be interested in knowing whether if you temporarily comment out suspect lines, if the issue goes away since it was a an absolute fails/works thing for me from just one particular line.

Or if it happens using the fresh-install /etc/sudoers that I post in my blog entry:

https://macperformanceguide.com/blog/2017/20170407_1157-macOS-10_12_4-sudo-broke n-fix.html

Have the same problem since 10.12.4 update.

Universal Workaround step by step:

1. open terminal.app

2. run "sudo visudo" (without the quotes)

3. wait 10 minutes

4. enter your password

5. use the cursor keys to navigate to each line starting with a '%' sign (those are group definitions)

6. press 'i' followed by '#' followed by the Escape key. (place a '#' in front of this line)

7. repeat step 6 for every line starting with a % sign.

8. place the Cursor at the beginning of any line (I recommend one near the group definitions)

9. press 'i' and enter your Username (e.g. "john"), followed by " ALL=(ALL) ALL", press enter and then the ESC key.

10. press ':' followed by 'x' and press enter.

Problem solved. This removes all Group-settings and puts a user-based permission for your user accoung (e.g. "john").

If you don't know your user account name, use the command "id -u -nr" in a new terminal window (not the one where you are working in just now).

You have to remove/comment-out every group definition in the /etc/sudoers file.

Apple needs to fix this, software installers depending on sudo scripts are hanging left and right

Juergen.

What does NOT work:

Fixes tried

1. On 2013 Mac Pro, rebooted into recovery mode and ran Disk Utility First Aid—no issues found. Problem remains.
2. Reinstalled macOS on the iMac 5K (did not wipe out drive first, did an “install over”). Problem remains.
3. Downloaded 10.12.3 combo installer; attempted to install over 10.12.4; this is not permitted.
4. On iMac 5K and MacBook Pro, made a brand-new admin account and brand-new standard account, logged into each of those accounts. Problem remains, proving that it is not an account-specific or machine-specific issue.

Per @yqowen post, re-installing sudo fixed it for me.

It was simple a matter of grabbing the latest sudo zip, running ./configure, make, make install.

- Installing a brand-new 10.12.4 on a freshly erased volume does NOT suffer the problem.

- Installing a brand-new 10.12.4 on a freshly erased volume and then using Migration Assistant on former system brings the problem back.

What works:

1. Do a fresh erase/install.

2. MANUALLY copy over data and reinstall all apps. Reconfigure all apps. Do NOT use Migration Assistant.

I've wasted 12 hours or more already beating my systems back into usable state (I use sudo a lot).

Apple has ignored the bug I filed on this for 12 days now (Apple Bug Report #31307973).

Quality control starts before shipping, but it seems that Apple has no concern with bugs once shipped. The last bug I filed was not looked at for 6 weeks, this one seems aimed in that direction.

I found the line causing the problem.

This line was in /etc/sudoers:

%users ALL= NOPASSWD: /sbin/kextload, /sbin/kextunload

Commenting it out, sudo behaves instantly with no delay. Since I do not understand the sudoers file very well, I don't claim to know why this works. But it all came down to this one line.

SOLUTION FOUND

I started commenting-out lines in /etc/sudoers. This single line was the problem. How that line got there I do not know (I never added it). Perhaps a remnant from, bygone days.

%users ALL= NOPASSWD: /sbin/kextload, /sbin/kextunload

Comment out the line like this, and all is well:

# %users ALL= NOPASSWD: /sbin/kextload, /sbin/kextunload

Thank you Juergen. I have found that it is not necessary to comment out more than a single line.

A few tips:

1) For those confused by visudo — TextWrangler works just fine, and then no need for all the character-based editing commands.

2) Another solution is to copy a fresh /etc/sudoers file from any fresh install of macOS 10.12.4, or from any Mac without the issue.

3) A few days ago I wrote up the single-line fix for the problem in this blog post on my web site:

https://macperformanceguide.com/blog/2017/20170407_1157-macOS-10_12_4-sudo-broke n-fix.html

Lloyd

As a shortcut for those who want a quick fix, here is a verbatim unmodified /etc/sudoers file from a fresh install of macOS 10.12.4. I suggest using TextWrangler to open /etc/sudoers and then simply replace the entire existing contents with this.

# # Sample /etc/sudoers file. # # This file MUST be edited with the 'visudo' command as root. # # See the sudoers man page for the details on how to write a sudoers file. ## # Override built-in defaults ## Defaults env_reset,timestamp_timeout=120 Defaults env_keep += "BLOCKSIZE" Defaults env_keep += "COLORFGBG COLORTERM" Defaults env_keep += "__CF_USER_TEXT_ENCODING" Defaults env_keep += "CHARSET LANG LANGUAGE LC_ALL LC_COLLATE LC_CTYPE" Defaults env_keep += "LC_MESSAGES LC_MONETARY LC_NUMERIC LC_TIME" Defaults env_keep += "LINES COLUMNS" Defaults env_keep += "LSCOLORS" Defaults env_keep += "SSH_AUTH_SOCK" Defaults env_keep += "TZ" Defaults env_keep += "DISPLAY XAUTHORIZATION XAUTHORITY" Defaults env_keep += "EDITOR VISUAL" Defaults env_keep += "HOME MAIL" Defaults lecture_file = "/etc/sudo_lecture" ## # User alias specification ## # User_Alias FULLTIMERS = millert, mikef, dowdy ## # Runas alias specification ## # Runas_Alias OP = root, operator ## # Host alias specification ## # Host_Alias CUNETS = 128.138.0.0/255.255.0.0 # Host_Alias CSNETS = 128.138.243.0, 128.138.204.0/24, 128.138.242.0 # Host_Alias SERVERS = master, mail, www, ns # Host_Alias CDROM = orion, perseus, hercules ## # Cmnd alias specification ## # Cmnd_Alias PAGERS = /usr/bin/more, /usr/bin/pg, /usr/bin/less ## # User specification ## # root and users in group wheel can run anything on any machine as any user root ALL = (ALL) ALL %admin ALL = (ALL) ALL ## Read drop-in files from /private/etc/sudoers.d ## (the '#' here does not indicate a comment) #includedir /private/etc/sudoers.d

I have the same issue that sudo hangs for every command execution after upgraded to 10.12.4, then I updated the sudo which downloaded from https://www.sudo.ws/download.html#binary, the issue was resolved, just FYI.

Let's see: sudo provides essentially root access to entire system.

So you go to a non-Apple site and download a replacement? A sudo binary not signed by Apple?

I assume it's a legitimate site (how would I know?!). The core idea of replacing a critical piece of the security infrastructure is deeply flawed vs fixing the problem in /etc/sudoers.

As you said, it's a legitimate site, although it's a non-Apple site.

And for other Unix like system which doesn't have sudo installed, we could use such as rpm to install sudo, and sudo.ws is just one of the rpm sources for sudo.

Actually, my /etc/sudoers do have correct settings, so the solution of edit /etc/sudoers didn't help me to resolve the issue.

Let's wait Apple to fix the issue, I have just tried to install the latest stable sudo on my MBP15 2016 version, and I'm pending to upgrade my Mac mini and MBA to 10.12.4 so far.

FYI， I have modification when I use 10.12.3 to below:

# root and users in group wheel can run anything on any machine as any user

root ALL=(ALL)NOPASSWD:ALL

%admin ALL=(ALL)NOPASSWD:ALL

%aaa ALL=(ALL)NOPASSWD:ALL

aaa is my default login, and belongs to admin, I added the NOPASSWD because I'm running some automation shells on this machine.

The description of 10.12.4 upgrade about sudo from Apple:

sudo

Available for: macOS Sierra 10.12.3

Impact: A user in an group named "admin" on a network directory server may be able to unexpectedly escalate privileges using sudo

Description: An access issue existed in sudo. This issue was addressed through improved permissions checking.

CVE-2017-2381