Apple - How do I prep a, temporary, root login before editing sudoers?

No backdoor is required, in fact really nothing (not even a backup) is required to edit the sudoers file. You can't get locked out of your machine.

A backup (sudo cp /etc/sudoers /etc/sudoers.bak) is more convenient though, because you can simply restore it with a one-liner.

Reasons:

1. sudoers is not required to authenticate a user at log-in
2. sudoers is not required to activate the root user with Directory Utility - only a working admin account. Authentication is done with the local OD services.
3. If you have a working Internet connection or a working local Recovery Mode (aka recovery partition) you can always restore the default sudoers file either from an online resource (e.g. pastebin or github) or as mentioned earlier: more convenient from a local backup file.
4. If you have a second Mac and some fitting cable you can always start the "broken" Mac in Target Disk Mode and transfer a working good sudoers file from the second Mac.

---

Tested in a Mojave VM by:

1. simply removing the sudoers file completely
2. editing sudoers with nano and commenting out the root and %admin line, changing ownership of sudoers to 501:staff and make it 777

Proof:

With due respect to the other folks who have offered suggestions so far, they are offering far more complicated ideas than are necessary.

Here is the simple truth: from at least 10.11 onward, there is no need to ever touch your /etc/sudoers file. None. Just leave it alone.

Look at the bottom of the /etc/sudoers file and you will see these lines:

## Read drop-in files from /private/etc/sudoers.d
## (the '#' here does not indicate a comment)
#includedir /private/etc/sudoers.d

What that means is that you can put files in /etc/sudoers.d/ and sudo will read them as if they were in the main sudoers file without ever having to touch the official sudoers file.

(In some versions of macOS, you may need to create the folder via sudo mkdir /etc/sudoers.d/ but in recent versions, it already exists.)

You can create/edit the file like this:

sudo visudo -f /etc/sudoers.d/foo

When you exit the editor, visudo will check the syntax for you, but even if you ignore the warnings and save it anyway, sudo will ignore any file in /etc/sudoers.d/ which does not have the correct syntax, but your main sudoers file will remain intact and working.

You can run sudo visudo -c to check the syntax of any/all sudoers files, and to show that they are being read/included.

Files in /etc/sudoers.d/ should be owned by root, they should be chmod 440 and they should not have any file extension (i.e. “foo” is ok but not “foo.txt”) If you create the file using visudo it will automatically be given the correct permissions.

(Oh, and you don’t need to enable root on a Mac. I’ve used one since 2003 and done all sorts of weird stuff but I’ve never needed it.)

---

If you ever do manage to screw up your /etc/sudoers file, you can use BBEdit to edit the file. It will prompt you for your admin password, but once entered, it can edit the file and remove the offending line. But you should still never edit the /etc/sudoers file.

macOS is a bit safer than most unixish OSes in this respect, since it has paths to root that don't depend on sudo. If you do mess up /etc/sudoers, there are several ways to recover (even without advance preparation, aside from backing up /etc/sudoers):

• Run the Directory Utility (it's hidden in /System/Library/CoreServices/Applications, but Spotlight can find it). Click the padlock and authenticate, then choose Edit menu > Enable Root User, and enter a root password. When you're done with root, you can disable it the same way.

• You can use AppleScript's do shell script ... with administrator privileges to run shell commands as root. Open /Applications/Utilities/Script Editor, and enter something like this:

  do shell script "cp /etc/sudoers.bkp /etc/sudoers" with administrator privileges
  

  ... and press the run (right-pointing-triangle) button in the toolbar. Authenticate when prompted.

Then there's also the simple & universal method: before messing with /etc/sudoers, run sudo -s to open a root shell and leave it open so you can use it to recover if necessary. It obviously won't survive a reboot, but you can do basic tests on your new /etc/sudoers before rebooting.