sudo problems

[DTigerpaw]

[Note: This is for OS X 10.8 Mountain Lion since 10.9 Mavericks is incompatible with apps I use daily.]

I've been a unix admin since the 80's, moving around between BSD, linux and the rest of them. I'm a command line junkie. I have a few Macs and they've always been good to me, but something odd is gnawing at me. Last year, I received an update and then I wasn't allowed to sudo anymore.

$ sudo
sudo: can't open /private/etc/sudoers: Permission denied
sudo: no valid sudoers sources found, quitting

I couldn't believe it was an update that did this, so I was going to try this:
Reboot, Opt-S
/sbin/fsck -fy
/sbin/mount -wu /
/bin/chmod 1775 /
/bin/sync
exit

but single user mode doesn't work for me. At all. Pressing Opt-S seems to be ignored.

And this isn't just one one Mac, I have an Air, two MBPs, two Minis, one Pro 4,1... I can't get this to work on any of these systems. So, i decided to wipe the drives and reinstall OS X clean.

I still get the same error as above. No access to sudo at all. And this is after I never installed a single app or even connected it to a network. A fresh install doesn't allow me, the admin, installer, any root access. Trying to 'passwd root' gets me nowhere.

Here's the research I found:

$ ls -la /private/etc/sudoers
-r--r----- 1 root wheel 1275 Apr 24 2013 /private/etc/sudoers

$ sudo dscl . -append /Groups/wheel GroupMembership MyUserName
-bash: $: command not found

$ ls -lad /private/etc /private
drwxr-xr-x@ 6 root wheel 204 Apr 24 2013 /private
drwxr-xr-x 101 root wheel 3434 Jun 6 12:11 /private/etc

$ ls -la /usr/bin/sudo
-r-s--x--x 1 root wheel 164496 Sep 19 2013 /usr/bin/sudo (Here, the '/usr/bin/sudo' is highlighted red in the terminal.)

$ sudo grep admin /private/etc/sudoers
sudo: can't open /private/etc/sudoers: Permission denied
sudo: no valid sudoers sources found, quitting

ls -lad /
drwx---rwx+ 39 root wheel 1394 Jun 6 12:12 / (The '/' is highlighted in yellow)

$ ls -alO /Volumes
total 8
drwxrwxrwt@ 5 root admin hidden 170 Jun 6 12:12 .
drwx---rwx+ 39 root wheel - 1394 Jun 6 12:12 .. (The '..' is highlighted in yellow)
lrwxr-xr-x 1 root admin - 1 Jun 6 12:12 Macintosh HD -> /
drwxrwxr-x 12 MyUserName staff - 476 Apr 22 15:11 [TimeMachineBackup]
drwxrwxr-x 22 MyUserName staff - 816 May 12 12:21 [External Raid5 array]

This, to me is straightforward and self-explanatory in any normal circumstance, but there's something here I'm missing and I can't identify it. Any assistance would be greatly appreciated.

 

[satcomer]

This is the warning taken from the sudors slash warning:

This file MUST be edited with the 'visudo' command as root.
# Failure to use 'visudo' may result in syntax or file permission errors
# that prevent sudo from running.

So you didn't use this command that is why it failed.

 

[chown33]

1. Post the output of:

/usr/bin/printenv | /usr/bin/sort ; /usr/bin/id

2. If you use a full pathname for the sudo command, describe what happens. E.g.:

/usr/bin/sudo id

3. The 'ls' command will list setuid executables in red if colors are enabled. See the man page for ls, and find the word "color":
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/ls.1.html

4. Use bash's builtin 'type' command to tell you what the path to an unadorned 'sudo' is (i.e. lone 'sudo', absent any path or slashes). Post the output.

5. In the output shown here:

$ ls -alO /Volumes
total 8
drwxrwxrwt@ 5 root admin hidden 170 Jun 6 12:12 .
drwx---rwx+ 39 root wheel - 1394 Jun 6 12:12 .. (The '..' is highlighted in yellow)
lrwxr-xr-x 1 root admin - 1 Jun 6 12:12 Macintosh HD -> /
drwxrwxr-x 12 MyUserName staff - 476 Apr 22 15:11 [TimeMachineBackup]
drwxrwxr-x 22 MyUserName staff - 816 May 12 12:21 [External Raid5 array]

The permissions on .. (which will be "/", as the file-system root) seem overly permissive. Write-access to all? Really? The permissions on / should not normally be public-write. In particular, this is a potential security lapse, and it may be that sudo is seeing it and blocking further execution.

The security lapse is simple to explain: if any directories leading to a secure file (e.g. sudoers) are public-writable, then anyone can rename or reroute path components (directories) to any arbitrary unsecured location. This is insecure because trivally opens the system to spoofing of any kind (arbitrary privilege elevation).

The '+' sign at the end of the permissions signals that ".." has ACLs, which you can list with 'ls -le'. You should look at those, or even post them.


EDIT
Please use CODE tags, not a Courier font. Simply changing the font doesn't preserve spacing, so things like 'ls' listings are still hell to read because all the columns produced by inserting spaces go away.

You don't need to put your entire post in CODE tags, just the command-line inputs and outputs.