[NSFileManager] Is there an official workaround for this issue related to security in macOS 10.11 and later?

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

Replies

Is there an official workaround around this OS vendor bug?

If you’re looking for an official workaround, you should use an official support channel, namely a DTS tech support incident.

Share and Enjoy

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

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

OK so I guess this means that there are no Technotes or Release Notes about this that I would have overlooked.


For the record, intercepting the error through the delegate is not a solution as the same inadequate NSError * parameter is received.

OK so I guess this means that there are no Technotes or Release Notes about this …

Not that I’m aware of.

Share and Enjoy

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

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