unzip – "operation not permitted"

I have an AppleScript applet that is used by a range of people with various versions of macOS. A number of components are installed. One of those is FFmpeg. Some users are experiencing an error during the FFmpeg install process which I can't figure out. Here is the (I know, crude) code:


set ffmpeg_site to "https://evermeet.cx/pub/ffmpeg/"
set FFmpeg_page to do shell script "curl " & ffmpeg_site & " | textutil -stdin -stdout -format html -convert txt -encoding UTF-8 "

set ffmpeg_version_start to (offset of "version" in FFmpeg_page) + 8
set ffmpeg_version_end to (offset of "-tessus" in FFmpeg_page) - 1
set ffmpeg_version_new to text ffmpeg_version_start thru ffmpeg_version_end of FFmpeg_page
set downloadsFolder_Path to "Users/[home]/Desktop"

set ffmpeg_download_file to quoted form of (downloadsFolder_Path & "/ffmpeg-" & ffmpeg_version_new & ".zip")

do shell script "curl -L " & ffmpeg_site & "ffmpeg-" & ffmpeg_version_new & ".zip" & " -o " & ffmpeg_download_file

set copy_to_path to "/usr/local/bin/"
try
  do shell script "unzip -o " & ffmpeg_download_file & " -d " & copy_to_path with administrator privileges
  do shell script "chmod a+x /usr/local/bin/ffmpeg" with administrator privileges
on error number -128
  -- Trap case where user cancels admin credentials dialog
  main_dialog()
end try


Most users have no problem. But, a few users have reported the following:


error: cannot open zipfile [ /Users/[home]/Desktop/ffmpeg- 4.2.2.zip ]

Operation not permitted

unzip: cannot find or open /Users/[home]/Desktop/ffmpeg- 4.2.2.zip, /Users/[home]/Desktop/ffmpeg-4.2.2.zip.zip or /Users/[home]/Desktop/ffmpeg-4.2.2.zip.ZIP.


Those people are all using macOS Catalina. I can't figure out what is causing the error.

  • I have tested the applet on a clean install of Catalina and had no errors.
  • It appears those users do have permission to access /usr/local/bin – the applet installs another component in that folder earlier in the install sequence (in that case the executable is saved into /usr/local/bin using a call to "curl"). Users are also able to manually copy FFmpeg to that folder.
  • The FFmpeg download is completed – users are able to extract the executable from the Zip file and move it to /usr/local/bin using other unarchive tools e.g. Keka – suggesting that the Zip file is not corrupted.
  • Users confirm they have entered their admin credentials correctly.


I can't figure out why this is happening to just some users. I believe other users on macOS Catalina have had no trouble. My own testing on a Catalina clean install produced no errors.


My only guess at present is that there is a problem for UnZip with the permissions on the downloaded FFmpeg file. But, I have nothing to show tbat is the cause and why it would only affect a few Catalina users.


Can anyone help with ideas on the possilbe cause ?


Thanks.

Replies

It’s unlikely that this is related to the destination directory but rather the source directory. macOS 10.15 added new user data protections for common user directories, like Downloads and Desktop. See WWDC 2019 Session 701 Advances in macOS Security for the details.

Accessing these directories is meant to trigger a permission alert which allows the user to grant or deny the access, but in some cases that doesn’t happen. This is typically because of the system doesn’t know that the program doing the access is associated with a GUI app. It’s easy to imagine that being the case here, where you’re running

unzip
using AppleScript authorisation trampoline (
with administrator privileges
).

I have tested the applet on a clean install of Catalina and had no errors.

Did you get the permission alert in that case?

Note My advice on this front is to set this stuff in a VM. That way you can re-test over and over again by restoring from a snapshot you took before the test. That’s important because the system caches a lot of security-related decisions, and it’s not easy to clear those caches.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Update: Using tccutil I have reset all permissions on a test laptop (tccutil reset all) and specifically the Desktop folder access (tccutil reset SystemPolicyDesktopFolder). But, re-installing my applet does not trigger any folder access permission requests or errors with UnZip.


I'd rather not have to create a VM for this at present. Is there another way to set up a Catalina install so that I can see all permission requests ?


Thanks.





[Many thanks for all this. Yes, that seems highly likely to be the cause. At least one user did have the error on a clean install. When run for the first time, the applet does generate a collection of Automation and Accessibility permission requests. But, I don't remember seeing any permission request regarding the Desktop or any file/folder access. I shall go through the WWDC session you've linked. I generally use tccutil to clear out permissions but a VM is much more rigorous.


Cheers.]

Is there another way to set up a Catalina install so that I can see all permission requests ?

I know of three tricks here:

  • A VM

  • tccutil
  • A new user account

The last one only makes sense if the privilege is per user. Most of them are not, but if there were a good candidate then Files & Folders would be it. It’s easy to determine this though; change the setting for one user and see if the other user sees that change.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thanks again. A VM is a bit much for me at present as it will have to be installed on a patched Mac – I don't have a Mac which is supported by Catalina.


Anyway, I did another "tccutil reset all", deleted FFmpeg (from /usr/local/bin), created a new user, logged into that user, started the applet and UnZip installed FFmpeg without error. There was no request for permission to access the Desktop folder. Perhaps running on a patched Mac is changing how Catalina handles this situation especially as SIP is disabled. But, the Automation and Accessibility permissions are fully enforced and it would be odd for just one kind of permission not to be enforced, surely.


One user definitely did have the "Files and Folders" permission dialog, they clicked on OK, and UnZip still caused the "Operation not permitted" error. That might be due to the shell commands not being blocked by the permission request (despite what Apple engineers said at the WWDC). Also, I've found that Accessibliity permission requests do not halt the applet which continues on to report an error because it can't use GUI scripting.


Without being able to trigger the error on my Macs, I'll just take a couple of pokes into the dark: first will be to broaden the existing Try block to trap all errors and second, to issue a chmod on the downloaded Zip files to make sure the user has all the file permissions they need before Unzip runs.


UPDATE 13/3/20: Also, have decided to download the zip file to usr/local/bin. That avoids the question of Catalina file and folder permissions all together.


Cheers.