Context
In macOS 10.11, the com.apple.rootless extended attribute was introduced (for SIP AFAIK).
So system applications in /Applications have a "com.apple.rootless" extended attribute set on their .app directory.
Now, let's image we write the following hypra complex command line tool:
#import <Foundation/Foundation.h>
int main(int argc, const char * argv[]) {
@autoreleasepool {
NSError * tError;
if ([[NSFileManager defaultManager] copyItemAtPath:@"/Applications/Image Capture.app"
toPath:@"/Users/Shared/Image Capture Copy.app" error:&tError]==NO)
{
NSLog(@"%@",tError);
}
}
return 0;
}
It woud be reasonable to expect this to work fine considering that if you use the Finder to copy the .app, it works perfectly fine.
Of course, - [NSFileManager copyItemAtPath:toPath:error:] will return NO.
2018-03-22 22:57:29.739730+0100 testCopy[806:22972] could not set attributes com.apple.rootless on destination file descriptor: Operation not permitted: Operation not permitted
2018-03-22 22:57:29.787798+0100 testCopy[806:22972] Error Domain=NSCocoaErrorDomain Code=513 "“Image Capture” couldn’t be copied because you don’t have permission to access “Shared”." UserInfo={NSSourceFilePathErrorKey=/Applications/Image Capture.app, NSUserStringVariant=(
Copy
), NSDestinationFilePath=/Users/Shared/Image Capture Copy.app, NSFilePath=/Applications/Image Capture.app, NSUnderlyingError=0x100509ee0 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}}
Program ended with exit code: 0
This API fails because it can not set the extended attribute. And the return NSError * object does not contain the correct information about the origin of the problem.
So we have 2 bugs in one:
- Bug #1: NSFileManager copy API is buggy because the code erroneously try to set an extended attribute it can not set when SIP is enabled.
- Bug #2: The NSError * does not correctly report the problem because the copy has actually been made, it's just that the extended attribute could not be set (would the extended attribute be set in files/folders within the .app bundle, yes the error would a bit more acurate).
This bug was introduced in macOS 10.11 and is still there in macOS 10.13.3.
Question
Is there an official workaround around this OS vendor bug?
Note
The bug has already been filed on radar: #38768496