macOS Permission denied for a binary

[moivhod]

I'm coding an app, which downloads and then extracts certain rar files purchased by customers. For rar unpacking I execute (with a command line) a binary file called unar from this project: http://unarchiver.c3.cx/commandline And this unar is downloaded by app as well and is placed along with rar files.

According to Mac OS policies downloaded unar has only read and write permissions and no executable one.
I've tried to change permission attributes with a command: chmod 777 unar. After that I see that attributes are changed to -rwxrwxrwx, but execution is still denied with an alert message: "dyld: bad external relocation length" and after it: "Trace/BPT trap: 5"

So how can I set the executable permission correctly for a binary file using command line?

 

[lloyddean]

Very short answer - you can't, it's not allowed.

 

[moivhod]

Very short answer - you can't, it's not allowed.

How come? Have robots prevailed the humans?)))

 

[Nermal]

The linked "unar" seems to work as expected on my 10.12.4 system, without having to change permissions (they defaulted to 755). Does it fail immediately for you, when called with no parameters, or is it when you do something specific?

 

[moivhod]

The linked "unar" seems to work as expected on my 10.12.4 system, without having to change permissions (they defaulted to 755). Does it fail immediately for you, when called with no parameters, or is it when you do something specific?

Yes, if I place unar in the system "manually" - it works perfectly with command like: ./unar archive.rar
BUT when it's downloaded by the app I'm coding it doesn't have the necessary attributes to be executed.

 

[moivhod]

I've noticed one thing - if unar comes to the system inside a zip - either being downloaded or copied from flash drive - it works ok. But if it's placed there both ways but as a raw binary - permission is denied and even chmod 777 doesn't help

 

[chown33]

Use this command on the malfunctioning binary:

ls -leO@  PATH_GOES_HERE

Post the complete output.

This command will show all the extended attributes, ACLs, flags, etc. Maybe one of them, such as the quarantine attribute, is contributing.

 

[moivhod]

Use this command on the malfunctioning binary:

ls -leO@  PATH_GOES_HERE

Post the complete output.

This command will show all the extended attributes, ACLs, flags, etc. Maybe one of them, such as the quarantine attribute, is contributing.

Tried the command line for unar binary and had returned:

-rw-r--r--@ 1 admin staff - 3707772 7 май 10:08 unar
com.apple.metadata:kMDItemDownloadedDate 53
com.apple.metadata:kMDItemWhereFroms 71
com.apple.quarantine 57

I didn't like that "com.apple.quarantine" and removed it with the line: sudo xattr -r -d com.apple.quarantine unar. The quarantine attribute was gone. But unar still had permission denied.

 

[chown33]

Tried the command line for unar binary and had returned:

-rw-r--r--@ 1 admin staff - 3707772 7 май 10:08 unar
com.apple.metadata:kMDItemDownloadedDate 53
com.apple.metadata:kMDItemWhereFroms 71
com.apple.quarantine 57

I didn't like that "com.apple.quarantine" and removed it with the line: sudo xattr -r -d com.apple.quarantine unar. The quarantine attribute was gone. But unar still had permission denied.

Then you should probably compare the binary that's downloaded with the binary that works. The 'cmp' command can do this.

Another useful tool for peeking into executables: otool. It can tell you lots of things, so read its man page and pick some basic things before moving on to more detailed ones.

If you want to peek at the hex bytes:

hexdump -C PATH_TO_FILE

The strategy here is quite simple: find the difference. If A works and B doesn't, but A and B are supposed to be identical, then find the difference. If there's no difference in the actual files or their direct metadata, then you expand the search to include things like file-system, user, environment, etc. In short, if the files are the same, and their metadata is the same, look in a larger context.


If you're planning on distributing your app on the Mac App Store, you won't be able to download executables. This is an App Store restriction, for what should be obvious security reasons.

I don't think the App Store allows executables other than the app itself in the app bundle, either. You should check the App Store terms to determine this.

 

[cqexbesd]

chmod 777 unar

You don't want 777 - it allows any user to write to the binary so they could change it to do anything - and then it would be run by your program as some other user.

You probably want something like 500 or even 100 but read up and decide for yourself based on your use case.

After that I see that attributes are changed to -rwxrwxrwx, but execution is still denied with an alert message: "dyld: bad external relocation length" and after it: "Trace/BPT trap: 5"

So how can I set the executable permission correctly for a binary file using command line?

I don't think your failure from the linker has anything to do with permissions - not of the binary itself anyway. If you didn't have permission to run the binary then the runtime linker would never have got called. I would suspect your binary is corrupt or for the wrong platform. Double check that first.

Andrew