"Operation not permitted" for command line script, Full Disk Access granted

Question

"Operation not permitted" for command line script, Full Disk Access granted

I have System Integrity Enabled, and have granted Full Disk Access to Terminal. In the Terminal, as any user including root, running the script test.sh yields:

./test.sh: Operation not permitted.

for the script in test.sh as:

-------

#!/bin/bash

ls

-------

On other computers with essentially the same setup, the script works without a problem.

Some scripts work and others do not. Sometimes, when I edit a script and modify the #! line in various ways and save, eventually the script runs. But I cannot see any consistency.

I tried "csrutil reset" and rebooting. Cleared all caches with TinkerToolSystem.app and rebooted. I cannot find any log entries, there must be someplace where SIP logs issues, but I did not find it.

I tried installing iTerm2 and granting that program Full Disk Access. Same result.

Thanks for any suggestions.

iMac Line (2012 and Later)

Posted on Oct 22, 2019 2:25 PM

Reply

Answer 1

Best reply

Steven Frank2 Author

Level 1

11 points

Oct 22, 2019 4:34 PM in response to HWTech

Yes, script is executable, in current working directory, and called as ./test.sh, Mojave 10.14.6.

I changed script to

----------

#!/bin/bash

/bin/ls

----------

and it worked. Then "/bin/ls" back to "ls" and it worked. Some sort of caching or passing of initial check?

The initial failure was actually with #!/usr/bin/env python3, in which python3 is a link in /opt/local/bin that goes to another directory for the current python 3 version. I have tried various combinations, and now all such python scripts work, whereas they previously failed.

In any case, now I cannot find any combinations that do not work. So thanks very much.

Is there some sort of caching of acceptable commands? Or, as it seems, some initial test that, once passed, is not used in future calls?

Reply

Answer 2

Oct 24, 2019 3:59 AM in response to VikingOSX

For what its worth I find it generally best practice to always define the full path to executables in scripts. This has two important benefits.

By specifying the full path you ensure you are running a copy of that command in a specific place and prevent the possibility of someone/thing modifying your path to run a dodgy copy in a different location
I have found that cron as an example when running a script does not have the same path definition and therefore might not find the executable and hence cause the script to fail even though when you test it by manually running it, it works

Reply

Answer 3

Oct 23, 2019 7:26 PM in response to Steven Frank2

If your default shell is zsh, as it is in Catalina, then unless you have a ~/.zprofile exporting your PATH when you launch Terminal and initiate a login zsh shell, or the ~/.zshrc file to set the PATH when you interactively switch between shells — nothing will work right. By changing a shebang to /bin/bash, you are reading Bash specific startup information, and your PATH is getting exported as it did when Bash was the default shell.

This is what I have in my ~/.zprofile and ~/.zshrc files in my home directory:

export PATH=".:$HOME/bin:/usr/local/bin:$PATH"
autoload -U colors && colors
MyHost="$(/usr/sbin/networksetup -getcomputername)"
PS1="%{$fg[blue]%}${MyHost}: %~ %{$reset_color%} %% %{$fg[white]%}"
export EDITOR="/usr/bin/vim"
export HOMEBREW_NO_ANALYTICS=1
export MAXOSX_DEPLOYMENT_TARGET=$(sw_vers -productVersion)

And here is the zsh prompt:

Not all of that content above is necessary.

Reply

Answer 4

HWTech

Level 9

56,714 points

Oct 22, 2019 3:56 PM in response to Steven Frank2

Not to be insulting, but is the script marked as executable?

Have you tried using the full path to the "ls" utility within the script?

Is the current working directory in the same directory as your script?

What version of macOS? If you are using Catalina, the default shell is now zsh, so $PATH may be different from what you had set with BASH. You can still revert to BASH if you want.

Reply

Answer 5

HWTech

Level 9

56,714 points

Oct 23, 2019 6:40 PM in response to Steven Frank2

I don't know. Maybe double check the $PATH, your BASH shell settings ("~/.bash_profile", "~/.bashrc", etc. ) and which shell you are actually using:

echo  $PATH
echo  $SHELL

I'm not that familiar with the nuances of the macOS command line which can cause me trouble with the few times I use it since it can behave differently than Linux which I'm familiar with. Maybe another more experienced contributor may know more about the macOS command line behavior.

Reply

Answer 6

Oct 23, 2019 7:02 PM in response to HWTech

Thanks for the followup. I don't think it is the shell, because it happened with python scripts. The path seems to be an issue, but in some strange way, because the paths are set correctly. Instead, there seemed to be some initial test by the System Integrity Protection (SIP) system with regard to paths that, once passed, was not checked again. That seems very OS X specific and a bit obscure. In any case, I have not seen further problems yet.

Reply

Answer 7

Oct 24, 2019 5:02 AM in response to John Lockwood

Thanks to both VikingOSX and John Lockwood. That is all great advice. However, I am certain that the problem in this case was some sort of weird interaction with SIP.

I am running Mojave, not Catalina. My default shell is /bin/tcsh. My path is set correctly, and works in scripts. After I set an explicit path, ran the offending script, and then reset the paths to the originals, everything worked, even after quitting Terminal and restarting. So I do not see how the path itself would have been the problem alone, instead of an interaction with SIP. I do agree that explicit paths are good in general. In cron, I always use explicit paths. But in this post I was trying to figure out why this particular computer was having a weird SIP issue.

Reply

"Operation not permitted" for command line script, Full Disk Access granted

Similar questions