Friday, July 30, 2021
Tags
IOException 1 and code signing issues
Friday, July 30, 2021 - Sam Rowlands
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 Ohanaware App Kit 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, so I can reset the permissions.
Except Permissions Reset says I already have read and write permission to the file, maybe there’s a bug in Permissions Reset, 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 to check.
No ACLs, but wait there an extended attribute labelled “com.apple.macl”. You know what, lets just use Permissions Reset 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.
- Jeff Johnson's article comes up Undocumented Catalina file access change You need to disable SIP to remove this new attribute.
- Howard Oakley suggests copying the file to a non-bott volume, stripping xattrs and then copying it back.
- Michael Tsai's info Persistent File Access via com.apple.macl Xattr
Back to my file, how did "com.apple.macl" get there in the first place and why is it a security problem now? Don’t know.
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 Ohanaware App Kit update.