Permission denied for a binary

moivhod

macrumors newbie
Original poster
Apr 8, 2017
9
0
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?
 

Nermal

Moderator
Staff member
Dec 7, 2002
18,678
1,183
New Zealand
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

macrumors newbie
Original poster
Apr 8, 2017
9
0
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

macrumors newbie
Original poster
Apr 8, 2017
9
0
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

Moderator
Staff member
Aug 9, 2009
8,360
4,343
Gourd City
Use this command on the malfunctioning binary:
Code:
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

macrumors newbie
Original poster
Apr 8, 2017
9
0
Use this command on the malfunctioning binary:
Code:
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

Moderator
Staff member
Aug 9, 2009
8,360
4,343
Gourd City
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:
Code:
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.
 
Last edited:

cqexbesd

macrumors regular
Jun 4, 2009
158
24
Germany
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