Sparkle not compatible with Lion sandbox #163

Closed
GerTeunis opened this Issue Mar 3, 2012 · 12 comments

Comments

Projects
None yet
7 participants
Contributor

GerTeunis commented Mar 3, 2012

As developers start to move to lion's sandbox this is becoming a massive problem.
During update the complete application crashes in lion sandbox mode (no, not MAS!)

The update is downloaded, installed but the relaunch crashes.

Any plans to make this work? It's a big issue.

Contributor

andymatuschak commented Mar 5, 2012

I thought we had another issue for this, but I can't find it, so we'll let this be the primary one.

My understanding is that we can make this work by performing the installation from a non-sandboxed service contained within a sandboxed app bundle.

I'm not entirely sure how this will mesh with the fact that finish_installation is an app (i.e. it shows UI). Can a sandboxed app contain a non-sandboxed app in its contents directly? Certainly, such a thing is forbidden by MAS guidelines, but what about the sandbox system itself?

I will not have time to work on this personally anytime soon. Patches are welcome.

wbyoung commented Mar 19, 2012

From the docs:

An XPC service can inherit the sandbox of the main application, or it can have its own sandbox. Putting the XPC service in its own sandbox allows you to implement privilege separation.

This seems to indicate that a Sandboxed app would not be able to create an XPC service unless it is also sandboxed, but that it could have different entitlements.

The sandbox is currently giving the following messages while Sparkle tries to remove the finish_installation.app from quarentine:

deny file-write-xattr path/to/finish_installation.app

There are no temporary entitlements for this, so the first thing to confirm is that it'd be possible to handle the finish_installation piece of Sparkle's auto-update without removing those file attributes. Can this app be run in-place instead of being copied in to the application support folder?

Even if the attributes were removed from the installation app to bring it out of quarantine, there'd be a bunch more issues like having the proper privileges to move an application to the trash and/or start another application. This seems possible based on the XPC and sandboxing documentation, but I haven't spent much time with it.

Contributor

andymatuschak commented Mar 20, 2012

This seems to indicate that a Sandboxed app would not be able to create an XPC service unless it is also sandboxed, but that it could have different entitlements.

My understanding is that it is not necessary to subject one's XPC service to the same sandboxing profile as its parent app.

Can an XPC service show UI? I don't know. Hm.

The sandbox is currently giving the following messages while Sparkle tries to remove the finish_installation.app from quarentine:

deny file-write-xattr path/to/finish_installation.app

There are no temporary entitlements for this, so the first thing to confirm is that it'd be possible to handle the finish_installation piece of Sparkle's auto-update without removing those file attributes. Can this app be run in-place instead of being copied in to the application support folder?

Interesting. It's not safe to run the app in-place because its in-place position is inside the app which will be replaced when it runs!

If we did not remove this app from quarantine, though, the system would prompt the user for their permission to run it, which would be extremely unfortunate. Maybe we can think of another way to achieve the same end.

Even if the attributes were removed from the installation app to bring it out of quarantine, there'd be a bunch more issues like having the proper privileges to move an application to the trash and/or start another application. This seems possible based on the XPC and sandboxing documentation, but I haven't spent much time with it.

Given that all of that is performed by finish_installation, and in this scenario, finish_installation would not be sandboxed, that should not be problematic.

wbyoung added a commit to wbyoung/Sparkle that referenced this issue Mar 20, 2012

Added an XPC service to deal with sandboxing.
This fixes #163. It requires that you copy the XPC service into your main application bundle in
Contents/XPCServices and runs the remove from quarantine step of copying the finish_installation
app as well as launching finish_installation app outside of the sandbox. Sparkle will function
exactly as it does now for applications that do not copy the XPC service into their application
bundle.

wbyoung commented Mar 20, 2012

The way that I read the documentation, it seems to indicate that if an application is sandboxed, the XPC service would have to be sandboxed as well (even if it had different entitlements). In fact, this does not seem to be true. An XPC service can run un-sandboxed (which is good for us). This is either a documentation bug or Apple is writing it from the perspective of applications in the Mac App Store (where sandboxing would be required for XPC services).

I made the XPC service handle the removal from quarantine as well as running the finish installation task, so everything should now work fine with sandboxing. There's more info in my commit, but it might be good to update some documentation if you accept this pull request to tell people how to enable the XPC service if they've sandboxed their app.

I'd be interested taking a look at this and also helping on some impl if required. I'm at the point of considering how we might provide a sandboxed non-MAS variant of our apps (shinywhitebox) to keep some consistency, and right now the update is certainly an issue.

I've yet to look at any code/XPC stuff as I'm still upgrading our build environments. Wanted to shout out and say "interested" if you'd like some additional help solving this.

wbyoung commented May 21, 2012

Help would be great. I haven't really had time to get back to this, but you can look at the comments in pull request #165 for how to proceed. The code in #165 works, but to get it integrated back into Sparkle, there's a bit more work to be done.

Contributor

samdeane commented Jul 4, 2012

@scornflake did you get anywhere with this? I need it too, so will happily give it a go if the work isn't already sitting in a fork somewhere.

Hi Andy,

Nope. I had intended to as part of new uploads to the MAS - but then Apple decided to allow "bug fixes" without sandboxing, so I decided to hold off on sandboxing our apps. However; I'll still be needing to do this at some point - all I've done for now is delay my requirement.

Contributor

samdeane commented Jul 5, 2012

Hi @scornflake, actually it was me (Sam Deane) and not @andymatuschak who was asking, but thanks for the answer in any case.

I've posted some more questions in the pull request, which I'm hoping that @andymatuschak or @wbyoung might be able to answer. Happy to help, but I don't know the code that well so it's probably worth getting a few answers before diving in and getting it all wrong...

Contributor

GerTeunis commented Aug 18, 2013

So, no more love for this?

"Select application in /Applications" NSOpenPanel would suffice? It will get added to the Powerbox and will allow the user to update the app. If you use the NSURL and make a security bookmark of it you can even ask it during the first update.

karlvr commented Aug 28, 2013

@GerTeunis would this result in an Open File dialog or similar? That seems a bit unpleasant. I'm rather new to sandboxing; that would enable the chosen application to run?

Owner

kornelski commented Dec 28, 2016

We track this in #363

@kornelski kornelski closed this Dec 28, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment