Permission denied for a binary

Discussion in 'Mac Programming' started by moivhod, May 6, 2017.

  1. moivhod macrumors newbie

    Joined:
    Apr 8, 2017
    #1
    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?
     
  2. lloyddean macrumors 6502a

    Joined:
    May 10, 2009
    Location:
    Des Moines, WA
    #2
    Very short answer - you can't, it's not allowed.
     
  3. moivhod thread starter macrumors newbie

    Joined:
    Apr 8, 2017
    #3
    How come? Have robots prevailed the humans?)))
     
  4. Nermal Moderator

    Nermal

    Staff Member

    Joined:
    Dec 7, 2002
    Location:
    New Zealand
    #4
    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?
     
  5. moivhod thread starter macrumors newbie

    Joined:
    Apr 8, 2017
    #5
    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.
     
  6. moivhod thread starter macrumors newbie

    Joined:
    Apr 8, 2017
    #6
    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
     
  7. chown33 macrumors 604

    Joined:
    Aug 9, 2009
    #7
    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.
     
  8. moivhod thread starter macrumors newbie

    Joined:
    Apr 8, 2017
    #8
    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.
     
  9. chown33, May 7, 2017
    Last edited: May 7, 2017

    chown33 macrumors 604

    Joined:
    Aug 9, 2009
    #9
    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.
     
  10. cqexbesd macrumors regular

    Joined:
    Jun 4, 2009
    #10
    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.

    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
     

Share This Page