'sweep' command installs itself into /usr/local and changes permissions, wreaking havoc on Homebrew

Sophos installs a sweep command into /usr/local/bin, and a few auxiliary files. Doing this, Sophos also changes ownership of /usr/local and several sub-directories. This wreaks havoc with Howebrew, which by default installs to /usr/local and expects it to be writable by the "main user". In general, /usr/local should not be used by non-user controlled installations.

A more polite way would be for Sophos to install its commands to /opt/sophos, and asking the user to and relevant paths if they wish to use the tools.

  • I have the same problem.  It appears Sophos changed permissions on a bunch of directories.  I ran this to undo the changes:

      sudo chown myusername:admin bin share share/man share/man/man1

    If this happens every time Sophos runs, that is going to get tedious quickly.

  • +1 to Simon's suggestion, and adding voice to his complaint. It's so invasive. There are soo many Homebrew users this impacts. Please fix it. Thanks.
  • Just another +1. This is terribly disruptive to my daily work.
  • Hey everyone,

    Just wanted to let you know, I've forwarded this feedback to our engineering team. I'll let you know what I hear back from them.

    Thanks for letting us know!

    Cheers,
    Serra
  • Yeah we've heard about this and we are planning to make a change in the near future (next few weeks) that will leave the permissions on directories alone if they exist (but set the reasonable values if we need to set them). Our own tools will always have restrictive permissions and ownership when installed.

    Curiously, Homebrew has a page about this that sort of suggests we are doing exactly what Apple is expected to be doing in their own updates. Anyone know if Homebrew plans a better strategy for /usr/local?
  • I've just been bitten by this as well. I understand Sophos wants their tools running with restrictive permissions & ownership, but this just isn't affecting Homebrew, Sophos is trampling on anything the user has installed in these locations.
  • In reply to bobcook:

    The purpose of /usr/local is to be used by the user, that's the convention and purpose of its existence.
    If Apple does it with their updates then Sophos shouldn't be trying to substitute itself to Apple anyway.
  • Bump. I've fixed all the warnings from `brew doctor` several times. I'm pretty sure this is the cause.
  • I just posted this on the forum sounds like the same problem? :I have a problem with about 200 imported image files that have _sophos listed as the Sharing & Permissions name. No idea how they got this but it means unless I change the permissions on all the files Aperture lists them as 'Unsupported Image Format'. If I select add a name to the permissions SophosEndpoint is listed as an option. SophosEndpoint is not listed in System preferences Users and Groups however. Sophos 9.4 Mac OS X 10.11
  • In reply to PeterBoyd:

    Hey everyone,

    Thanks again for all the feedback. Just wanted to let you all know that we're aware of this, and planning to fix it in a future release. I'll reply back when I have a specific timeline.

    Cheers,
    Serra
  • In reply to serra:

    Hey all,

    Just wanted to let you know that the fix for this should go out within the first half of November 2015.

    Cheers,
    Serra
  • In reply to serra:

    Thank you Serra. Would you be able to followup when the fix does go out along with the version number of the release so that we can all be sure to 1) update and 2) accurately report any lingering issues? Thank you again.
  • Glad to see a fix is coming. I've been temporarily getting around it by doing a `chgrp` to admin and `chmod g+w` to all of `/usr/local`. I read it's a good idea to NOT change the owner of /usr/local from root. After the fix, will doing this once prevent the permissions changing again?
  • In reply to StevenMajor:

    you bet I will! I just saw a notification that the fix is currently in QA so it's definitely in the works, and i'll let y'all know as soon as it's available.
  • Here is a bit of a workaround... Add this function to your ~/.bash_profile

    # Freshen up your brew.
    freshbrew() {
      me="$(whoami)"

      file1="$(stat /usr/local/bin | awk '{ print $5 }')"
      file2="$(stat /usr/local/share | awk '{ print $5 }')"

      if [ "$me" != "$file1" ]; then
        echo -e "Need to chown /usr/local/bin"
        sudo chown -R $(whoami):admin /usr/local/bin
      fi

      if [ "$me" != "$file2" ]; then
        echo -e "Need to chown /usr/local/share"
        sudo chown -R $(whoami):admin /usr/local/share
      fi

      brew doctor
      brew update
      brew upgrade
      brew cleanup
      brew prune
    }



    Source your bash_profile and then run it by typing freshbrew at the command prompt. If you need to chown, you'll be asked for your password. Otherwise, you won't and you'll be able to brew like normal.