6

I ran 

$ sudo chown -R $USER /usr/bin

and now when I try to run programs under the /usr/bin path as sudo I get 

sudo:must be setuid root

What should I do if I would like to revert the chown?

jerome
  • 203
  • 1
  • 2
  • 6
  • It's also possible that the filesystem was mounted with the nosuid option, in which case `mount -u /` should fix it (assuming you can get root privileges to do so!). – 200_success Nov 19 '12 at 04:54

4 Answers4

13

Run Disk Utility, select your boot volume, and use "Repair Permissions". Since the files in /usr/bin (including sudo) were installed as part of the OS, it knows what their ownership and permissions should be, and it'll set them back properly.

Gordon Davisson
  • 11,036
  • 3
  • 27
  • 33
  • Repair Permissions Not found – Gank Nov 18 '17 at 08:37
  • 1
    @Gank Repair Permissions was removed in El Capitan (OS X v10.11) because System Integrity Protection prevents most of the problems that Repair Permissions would fix (including changing perms on /usr/bin/sudo), *and* would prevent them from being fixed if they did get messed up. In order to even have this problem under El Capitan and later, you have to have disabled SIP or done something similarly weird, and the repair procedure is going to depend on that. Or you could just reinstall the same version over top of your current system (which should preserve user data and settings). – Gordon Davisson Nov 18 '17 at 08:57
  • Yes I disabled SIP before. I enabled it now but not work. How to solve it? Will reinstall system delete my data? – Gank Nov 21 '17 at 15:26
  • 1
    @Gank Reinstalling the same (or newer) version of macOS over the existing OS shouldn't delete your data (unless you explicitly erase the volume as part of the operation). *However*, installation has been known to fail and sometimes in ways that leave the disk unreadable. Also, the installer will remove modifications you've made to SIP-protected regions of the filesystem (not *just* the permissions on /usr/bin/sudo). So I strongly recommend making sure you have a good backup of everything you don't want to lose before trying to repair it. – Gordon Davisson Nov 21 '17 at 20:33
  • Perfect solved by what you said – Gank Nov 26 '17 at 14:22
1
xattr /usr/bin
com.apple.FinderInfo
com.apple.rootless

xattr -d <extended_attribute> /usr/bin

that will remove the attribute, so you can do the commands, then make sure you re-enable the attribute when you are finished:

xattr -w <extended_attribute> /usr/bin

that will re-enable the attribute.

Ozz

Ozz Nixon
  • 11
  • 2
0

You need to chown the files back to root and then chmod u+x all the programs that should be setuid root.

David Schwartz
  • 31,215
  • 2
  • 53
  • 82
  • 1
    `$ sudo chown -R root /usr/bin` ==> `sudo: must be setuid root` – jerome Sep 29 '11 at 02:33
  • Login as root in the first place. Don't try to use `sudo`. If you don't allow root logins at all (not even by `ssh`), you may have to boot to a recovery shell to fix it. – David Schwartz Sep 29 '11 at 02:35
  • I am the root user. If I run `chwon -R root /usr/bin` as that user, I get a bunch of `Operation is not permitted` messages for every program and file in `/usr/bin`. – jerome Sep 29 '11 at 02:42
  • Are you sure it's every file and program? It should just be the ones set system immutable, which you wouldn't have been able to mess up anyway. If you're 100% sure, you'll have to clear the system immutable flag by issuing a `chflags noschg` command, likely in single-user mode. – David Schwartz Sep 29 '11 at 02:45
0

I'm not familiar with OSX but in Linux, you can do it by running su - to login as root and chown -R root /usr/bin.

quanta
  • 50,327
  • 19
  • 152
  • 213