MacOS – Wi-Fi indicator error after bad chown command

You can check and re-assign ownership recursively over a directory tree with find, stat and chown.

#!/bin/bash

olduser=<oldusername> # replace this with your old username
newuser=<newusername> # replace this with your new username
dir=<dir> # replace this with the directory you want to run through

find $dir | while read filename
do
  owner=$(stat "$filename" | cut -d ' ' -f 5)
  if [ $owner == $olduser ]
  then
    chown $newuser $filename
  fi
done

If you want to use a non-root MacPorts installation you will have to configure your installation to do that by installing from source and specifying --with-no-root-privileges as argument to ./configure. Note that you might have to set --prefix, too, if you want to do that.

I would encourage you not to do that, for a couple of reasons, though:

• Directories listed in multiple users' $PATH that are writable without superuser privileges can be used for attacks (e.g., by placing a sudo binary that will log the password there). The same can be done by malicious software running as your user in order to get your password – although one might argue it's already too late when this happens.
• MacPorts can not use privilege separation without root privileges. Normally, MacPorts will drop privileges to an unprivileged "macports" user while building software to avoid rogue Makefiles to wreak havoc (or even read files) in your $HOME.
• MacPorts as of version 2.2 uses OS X sandboxing capabilities to prevent ports from installing files outside of the locations MacPorts encourages. These default locations are:
  • /opt/local
  • /Applications/MacPorts
  • /Library/LaunchDaemons/
  • some locations necessary for some special ports to work, e.g., /usr/lib/pam for PAM modules.

So, in conclusion, I think a MacPorts installing using root privileges is actually safer and more secure than one not using them.

Disclaimer: Since I'm a MacPorts Developer, I might be biased.