0
Hi, I just updated to OS X Sierra (10.12) directly from Yosemite (10.10), so I'm only discovering this issue now. But from poking around the web, it appears this is an issue that was introduced in OS X 10.11 (El Capitan). Having just installed new system software, I discovered that none of my scripts that rely on the cssend command are working. Since I have cssend installed in /usr/bin for convenience, I figured it probably didn't come over with the new install and I probably just had to install it again. In trying to do so, I'd follow the instructions in the cssend readme file about going into a Terminal session and executing the command. The system would ask me for my password, but then reject the command with an error stating that "Operation not allowed." I poked around a bit further and discovered that as of El Capitan, Apple is now restricting certain folders, and without a clunky process (described here: http://stackoverflow.com/a/32590885) to turn off system integrity protection, the user (yes, even the super user, and even the root user) cannot modify the /usr/bin folder. In reading about this problem, it's been suggested that the proper place for code such as cssend is /usr/local/bin, rather than /usr/bin. The former, /usr/local/bin, is not restricted by the system. I was able to successfully install cssend in /usr/bin after I followed the instructions in the link above, but this is really getting under the hood in a way that shouldn't be necessary. I know absolutely zero about ruby, path variables, etc. But since Apple seems serious about keeping us out of /usr/bin from now on, would it be possible for you to rewrite the cssend script so that it lives in /usr/local/bin instead of /usr/bin? Thanks!
Responses (3)
  • Accepted Answer

    Thursday, March 02 2017, 10:44 AM - #permalink
    0
    Matt,

    You are correct. Placing the cssend script file in /usr/bin is not allowed in OS X 10.11 and higher. The correct solution is to place the file in /usr/local/bin, as you pointed out. The cssend script file itself doesn't need to be changed.

    We have updated the readme file to reflect this.

    Thank you.
    The reply is currently minimized Show
  • Accepted Answer

    Friday, March 03 2017, 08:35 AM - #permalink
    0
    Thanks George. Just so I'm clear -- in the prior version of the script, the script's path variable included /usr/bin, and therefore if you placed the script in that folder, you could call cssend without declaring a path -- the system would just magically find it. If you placed it somewhere else, e.g. your documents folder, you had to declare the path to cssend in the command arguments or the command would fail.

    With cssend now in /usr/local/bin, is that functionality still available? I have hundreds of scripts that use cssend and I am not nuts about having to go through them one by one to explicitly declare a path to the script. I am a total noob when it comes to this sort of programming, which is I why I asked about what, if anything might need to be updated if cssend is not going to live in /usr/bin by default.

    Thanks!
    Matt
    The reply is currently minimized Show
  • Accepted Answer

    Friday, March 03 2017, 09:55 AM - #permalink
    0
    Matt,

    Yes, it will work exactly as before. The system will magically find the script. The /usr/local/bin is just another place for scripts that are registered with the system and available, except it is a place for users to put their scripts while /usr/bin stays protected. That's the simple way to describe it.

    Before OS X 10.11 it didn't matter as much which one of these folders had user scripts (like cssend), but Apple has been making OS X more secure and therefore the rules about what is allowed to go where are most strict. Which is good.

    Now that you managed to actually get the script into /usr/bin you can leave it there, or yo can reverse what you did and put it in /usr/local/bin. That's up to you. But ether way you don't have to change the hundreds of scripts that you have.
    The reply is currently minimized Show
Your Reply