sandbox question about copying from bundle

  • Hi,

    In the non-sandboxed version of my app upon first launch I copied a helper executable from my bundle to my application support folder (standard location) and communicated with it via nstask.  Now I'm trying to sandbox my app and I found that when I do this it fails with a read-write deny (sandbox application support location).  As a test I changed it where my app would communicate with this executable directly inside of my bundle and it seems to work.  So my question would be is this how it must be when it's sandboxed that I'm not allowed to copy resources out of my bundle into my own sandboxed application support location?

    Thanks,

    rc
  • On Jun 22, 2012, at 4:51 AM, Rick C. wrote:

    > Hi,
    >
    > In the non-sandboxed version of my app upon first launch I copied a helper executable from my bundle to my application support folder (standard location) and communicated with it via nstask.  Now I'm trying to sandbox my app and I found that when I do this it fails with a read-write deny (sandbox application support location).  As a test I changed it where my app would communicate with this executable directly inside of my bundle and it seems to work.  So my question would be is this how it must be when it's sandboxed that I'm not allowed to copy resources out of my bundle into my own sandboxed application support location?

    Are you sure it's copying the file into the sandboxed Application Support folder and not the real one? What method are you using to discover the location of the Application Support folder? The code isn't using a hard-coded path to the folder, is it? Are you sure that the folder actually exists before you put something into it? Would you please share with us the deny error you're getting from sandboxd? Your app should have full access to its sandboxed Library folder and subfolders.

    Nick Zitzmann
    <http://www.chronosnet.com/>
  • Ok here's my follow-up...I confirmed that everything I told you was true and finally said to myself I will just communicate with this executable inside my bundle.  This works until I submit it to the Mac App Store and I get invalid binary because this executable (3rd party) is not sandboxed.  So I give this binary entitlements and now when I try to communicate with it via NSTask it crashes and the crash report reveals that a sandbox cannot be created.  I thought that any of my resources carried the same sandbox anyways as my main app?  So now I still don't know what to do?  If I don't sandbox the executable it works but the App Store won't accept it, and if I do sandbox it the App Store (presumably) will accept it but it crashes.  What should I do?

    Thanks for the help in advance as I'm quite stuck here,

    rc

    On Jun 23, 2012, at 3:25 AM, Nick Zitzmann wrote:

    >
    > On Jun 22, 2012, at 4:51 AM, Rick C. wrote:
    >
    >> Hi,
    >>
    >> In the non-sandboxed version of my app upon first launch I copied a helper executable from my bundle to my application support folder (standard location) and communicated with it via nstask.  Now I'm trying to sandbox my app and I found that when I do this it fails with a read-write deny (sandbox application support location).  As a test I changed it where my app would communicate with this executable directly inside of my bundle and it seems to work.  So my question would be is this how it must be when it's sandboxed that I'm not allowed to copy resources out of my bundle into my own sandboxed application support location?
    >
    > Are you sure it's copying the file into the sandboxed Application Support folder and not the real one? What method are you using to discover the location of the Application Support folder? The code isn't using a hard-coded path to the folder, is it? Are you sure that the folder actually exists before you put something into it? Would you please share with us the deny error you're getting from sandboxd? Your app should have full access to its sandboxed Library folder and subfolders.
    >
    > Nick Zitzmann
    > <http://www.chronosnet.com/>
    >
  • On Jun 24, 2012, at 2:47 AM, Rick C. wrote:

    > Ok here's my follow-up...I confirmed that everything I told you was true and finally said to myself I will just communicate with this executable inside my bundle.  This works until I submit it to the Mac App Store and I get invalid binary because this executable (3rd party) is not sandboxed.  So I give this binary entitlements and now when I try to communicate with it via NSTask it crashes and the crash report reveals that a sandbox cannot be created.

    I haven't played with sandboxed helper apps yet, but I read the other day if the helper app is started via posix_spawn(), the helper apps should have exactly two entitlements:

    com.apple.security.app-sandbox YES
    com.apple.security.inherit  YES

    For helper apps start with XPC Services you can have a much richer entitlement set.

    My guess is that NSTask, because it is an older approach, uses posix_spawn(), so you might want to try and *only* give it the "inherit" entitlement.

    Todd
  • Yes that is right I was doing it wrong thank you very much!  Now the only other issue I had was am I not allowed to write my helper app to my application support folder and send NSTask to it there?  It seems this only works if I keep it inside of my bundle?

    rc

    On Jun 25, 2012, at 5:08 AM, Todd Heberlein wrote:

    >
    > On Jun 24, 2012, at 2:47 AM, Rick C. wrote:
    >
    >> Ok here's my follow-up...I confirmed that everything I told you was true and finally said to myself I will just communicate with this executable inside my bundle.  This works until I submit it to the Mac App Store and I get invalid binary because this executable (3rd party) is not sandboxed.  So I give this binary entitlements and now when I try to communicate with it via NSTask it crashes and the crash report reveals that a sandbox cannot be created.
    >
    > I haven't played with sandboxed helper apps yet, but I read the other day if the helper app is started via posix_spawn(), the helper apps should have exactly two entitlements:
    >
    > com.apple.security.app-sandbox    YES
    > com.apple.security.inherit            YES
    >
    > For helper apps start with XPC Services you can have a much richer entitlement set.
    >
    > My guess is that NSTask, because it is an older approach, uses posix_spawn(), so you might want to try and *only* give it the "inherit" entitlement.
    >
    > Todd
    >
  • That does make sense I was just looking for a definitive answer... :-)  Now I am writing my helper to the app support folder inside of my sandbox that's why I thought it might work, but it might not based on how you described it.  And I'm guessing it might also be possible that with the inherit entitlement the helper app must reside inside of the bundle that it's inheriting from?

    rc

    On Jun 25, 2012, at 9:10 AM, Todd Heberlein wrote:

    >> Yes that is right I was doing it wrong thank you very much!  Now the only other issue I had was am I not allowed to write my helper app to my application support folder and send NSTask to it there?  It seems this only works if I keep it inside of my bundle?
    >
    > I'm still a newbie with sandboxing, but it strikes me that that being able to execute a program located at an arbitrary location would break the sandbox concept. The rest below are just thoughts that come to mind…
    >
    >
    > I had read somewhere that sandbox apps can still read files in POSIX-readable locations, or something like that, so you might want to try some experiments where NSTask starts some of the standard UNIX programs like
    >
    > /usr/bin/whoami
    > /bin/ls
    >
    > If NSTask can do that, I suppose there is hope for running programs via NSTask that live outside your bundle. Next , try copying your helper program to /usr/bin/my_helper_app (or whatever it is called), and then try executing that.
    >
    > If that works, then you can run your helper app when it is one of those standard POSIX-readable locations.  Unfortunately, I have no idea what those are.
    >
    > Todd
    >
previous month june 2012 next month
MTWTFSS
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  
Go to today