Yesterday I tried to resume work on a project that I was working on the day before, except for some reason, the application was unable to auto-open the previous file.
I was getting an IOException with no message and error code 1. Looking up the error code over at https://osstatus.com/ gave me a big long list, through a process of elimination I ended up with “Kernel: Operation Not Permitted” and it referenced errno.h
The App Kit 2021 - Building Better Mac Applications has a function for getting a readable string from errno
errorMessage = macOSSystem.strerror( inerr.errorNumber )
So I created a new function called IOExceptionMessageMake which would read errno if the IOException doesn’t contain a message.
I’ve see the “Operation Not Permitted” error message a lot in recent years and so I assumed it was something to do with Apple’s “Security” protocols. Checking the permissions of the file in the IDE, reported that the file was unreadable and unwriteable. If I’m going to need to reset the files permissions, my users might also, so I modified the msgboxError function in the App Kit. It can now take an optional folderitem and offer the user the ability to reveal that file in the Finder.
Now I know where the file is, I open it in Permissions Reset 2, so I can reset the permissions.
Except Permissions Reset 2 says I already have read and write permission to the file, maybe there’s a bug in Permissions Reset 2, so I double check with Finder, shows the same, triple check in Terminal, shows the same. I have read and write access to the file, but my app is denied access. It must be an ACL then, lets use the Info button on Permissions Reset 2 to check.
No ACLs, but wait there an extended attribute labelled “com.apple.macl”. You know what, lets just use Permissions Reset 2 to blast all that meta data away… No dice, I then tried the terminal, nope, nothing I can do will remove the “com.apple.macl” attribute, whatever the #### it is.
Google Time… Uh oh… This is a new “Security” system introduced with macOS Catalina, and it’s not good. Undocumented Catalina file access change You need to disable SIP to remove this new attribute (or Howard Oakley suggests copying the file to a non-boot volume and then stripping it, then trying to copy it back Quarantine, SIP, and MACL: macOS per-file security controls – The Eclectic Light Company).
How did it get there in the first place and why is it a security problem now? Don’t know, but after some serious rewinding in my brain, I recalled that I’d disabled the App Wrapper script to test something out.
Re-enable the App Wrapper script and sure enough my app can now access that file again! The App Wrapper script affects the code signing of the application.
So I go back to my IOExceptionMessageMake function and add a quick check to see if the application is unsigned and report that. The new function is app.infoisCodeSigned.
Put it all together and now I get this.
These new functions will be available in the next App Kit 2021 - Building Better Mac Applications update.