sudo hangs before password

My bug report at Apple was finally looked at after 15 calendar days ⚠.

Apple closed it as "duplicate" so it is useless to update it. The duplicate bug number cannot be found (by me). So:

(a) any updates I do would be to my close bug, which would be useless.

(b) I have no idea what Apple is doing or will do since no response was added of any kind other than my bug marked as "Duplicate of 30585368 (Open)".

Very annoying to go to the trouble, wait 15 days, then get zero feedback and be locked out of knowing status (because I cannot find or see #30585368. At least not after trying many times.

https://macperformanceguide.com/blog/2017/20170328_1326-macOS-10_12_4-sudo-broke n.html

As far as I can tell the problem is just with the NOPASSWD attribute. Simply adding that to an existing non-admin user on an otherwise fresh 10.12.4 install triggers the problem for me. I'm going to create a bugreport for Apple, but I don't have high hopes. I'm surprised this hasn't been reported more widely.

UPDATE:

Much prior to the Sierra update when i installed my system under el-capitan, I have added a custom Group (using System Preferences) and assigned my User to that Group so i did not have to put it in the OS X admin group.

(Strict separation of privileges)

I then added this custom group "%mygroup ALL=(ALL) ALL" to sudoers file because i trust sudo more than OSX to handle privilege escalation (also sudo asks for the login password).

This has worked well until the last system update.

I have now found out that the latest update must have REMOVED this custom group ENTIRELY.

Which explains why sudo runs in to a >5 minute timeout - it simply cannot resolve the Group name!

(sudo binary hangs doing rpc calls to localhost which are dropped by OS X default)

The "Workround" ealier removed all group references, including the one to this group that is no longer there.

The FIX - at least in my case - is supposed to be simple:

Just add the group again and restore my sudoers file...

*BAM*

System Preferences hangs.

Fortunately only for a minute, and if one does not Force-kill it, the group is finally back and sudo works with custom groups again...

tl'dr: Bug is in custom group handling, custom groups were removed by this update, screwing up sudo.

Please disregard my previous reply, I was wrong. It's not the presence of the NOPASSWD attribute alone that triggers the issue but the fact that it appears on a group entry (i.e. a line that begins with %). I was furthermore using a non-existing group, which might have contributed to the issue. I've now added a user entry instead, with NOPASSWD, and it works fine.

edit: nice timing of your response J46256 🙂 It's clear now what the issue actually was: a non-existing group name!

In my case, the hang went away by commenting out the line:

%myusername ALL = (ALL) ALL

which was inserted below the usual line:

%admin ALL = (ALL) ALL

Please advise: is the "%" indicative of a Group? and there is no Group with my personal username?

I also have the same problem. My macbook air updated to 10.12.4 a day or two ago and I came to use sudo for the first time today and found that it just hangs for 5 or so minutes before it completes the action.

I finally got into my sudoers file but I do not have the "%users ALL= NOPASSWD: /sbin/kextload, /sbin/kextunload" line. All I had was this:

root ALL=(ALL) ALL

%admin ALL=(ALL) ALL

%DOMAIN\\Domain\ Admins ALL=(ALL) ALL

I had a hunch and commented out the domain admins line, and it now works fine. I haven't recently been on the network that has the AD controller that my account is on (the account is set as a mobile account so I can use it away from the network) but this hasn't been an issue until this update to 10.12.4.

GGendron wrote:

Please advise: is the "%" indicative of a Group? and there is no Group with my personal username?

Yes, %groupname references a Usergroup.

Can be local but also from a remote directory service (Apple Directory, NIS, Microsoft AD, LDAP ...)

The Bug seems to be that a Group name that is not a local group (check the file /etc/groups or SystemPreferences -> Users&Groups -> Groups list below the listed users) than "sudo" hangs with very long timeouts trying to resolve that group over dysfunctional RPC methods (a trace shows RPC calls over network against localhost that are not answered because there is no such RPC service running on a client).

Note that the group "admin" should always exist, as this is a fundamental part of Mac OS X user concept!

Only other (custom) groups appear to habe been deleted with the last update, breaking sudo.

Thanks for the fix, Juergen!

I found that removing the reference to the ONE group that did not exist in /etc/group fixed the problem for me.

I had a row in /etc/sudoers.d/alan that said "%sudo ALL=(ALL) NOPASSWD: ALL", but there was no group called "sudo". When I commented out that one line, the 4.5 minute delay went away.

My /etc/sudoers file still contains a group line for the "admin" group, which does exist in /etc/group.

Alan

if you are using Vagrant or any other software that may place sudo aliases or commands into `/etc/sudoers.d/`, make sure that you remove/disable these files.

For me, one of the Vagrant plugins created a file that was using group `sudo` that does not exist.

Thank you, guys, for troubleshooting this.

This is the correct fix. Any group (denoted by a '%' prefix in the sudoers file) MUST exist in /etc/group or System Preferences > Users & Groups.

I had a 'sudo' group in the sudoers file that was no longer in /etc/group (update must have clobbered it).

Doing a search and replace in visudo to change all instance of 'sudo' to 'admin' worked.

Thanks!

I was also facing this issue for almost 3-4 months, It was bugging me a lot. It made me almost mad. Yesterday i decided to sit down and fix this issue once and for all.

After lot of reading and all i found that AMPPS entry in sudoers file is culprit.

open sudoers file using sudo visudo command (take backup of sudoers file before making changes and also read guide to use "visodo" )

I commented 2 lines in my sudoers file and everything is fine now.

#%amit ALL= NOPASSWD: /Applications/AMPPS/Ampps.app

#%amit ALL= NOPASSWD: /Applications/AMPPS/ampps

Similar experience/solution has been shared by this blogger here, https://macperformanceguide.com/blog/2017/20170407_1157-macOS-10_12_4-sudo-broke n-fix.html

You might not be having AMPPS on your machine so what worked for me, might not work for you.

Point to highlight is "There is something in there in your sudoers file which is causing issue, just find that line"

See my post at the bottom of this thread.

https://discussions.apple.com/thread/7906178?answerId=31611413022#31611413022

I have this hang on three different Macs, all started with 10.12.4. Details at https://macperformanceguide.com/blog/2017/20170328_1326-macOS-10_12_4-sudo-broke n.html

If anyone has a solution, please contact me and I will write it up in my blog:

https://diglloyd.com/aboutlc.html