AuthorizationCreateFromExternalForm throwes .denied
#3
-
|
I managed to get authorization to bless my priv helper tool from my main app. I used the When I hit this line in the decoding: Blessed/Sources/Blessed/Authorization.swift Lines 107 to 109 in ef63245 I get a return value of
(PID Here's an chunk of the log (the line formats aren't consistent, because I was copy/pasting them weirdly)The odd thing is, Here's the codesign verification of the XPC service... and here's the codesign verification of the the helperOff the top of your head, do you have any trouble shooting ideas I could try? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 8 replies
-
|
At the point in time that your XPC helper tool performed the deserialization, did the The output of |
Beta Was this translation helpful? Give feedback.
-
Boom. Head shot! In the little demo app I made myself to test these waters, I had the AuthorizationRef stored statically, and never called
True. |
Beta Was this translation helpful? Give feedback.
-
|
What lifetime should my authorization reference? I could (for example) have it allocated when I call |
Beta Was this translation helpful? Give feedback.
-
That'd be perfectly reasonable. Doing that would effectively be the multi-process equivalent of Blessed/Sources/Blessed/LaunchdManager.swift Lines 86 to 121 in ef63245 Depending on your state management (such as using a |
Beta Was this translation helpful? Give feedback.
-
|
Funny enough, I was actually going to pitch the idea of moving lines 100-111 of that method into a new method, which just calls |
Beta Was this translation helpful? Give feedback.
-
I'm not interested in doing this as |
Beta Was this translation helpful? Give feedback.
-
|
I agree in general, but I think if there should be an affordance for one “convenience api” for blessing an app, it should be “authorizeForBless” (temporary name), not “authorizeAndBless”. I think this because:
|
Beta Was this translation helpful? Give feedback.
-
My understanding is authorization can only occur in a non-sandboxed app. If lines 100-111 were separately factored out, then line 111 would fail in a sandboxed app: I don't see this function as encouraging authorizing and blessing in a single process, so much as when that's the case, making it easy to do so. In the single process case, this seems like the way to both authorize and bless. In a multiprocess case there's a lot of intermediate steps which could differ and go beyond the bounds of this framework.
I don't think someone implementing this themselves would actually copy lines 100-111, they'd just compose the few lines that are actually applicable. Without the conditional logic, that'd look something like: let message = "Message here"
let icon = Bundle.main.url(forResource: "myIcon", withExtension: "png")!
let authorization = try Authorization()
_ = try authorization.requestRights([.blessPrivilegedHelper],
environment: [.forPrompt(message: message), .forIcon(icon)],
options: [.interactionAllowed, .extendRights])Providing a convenience wrapper for such little code seems odd. |
Beta Was this translation helpful? Give feedback.
-
|
Well I might be a single data point, but for example, I didn't know that you could specify the authorization prompt/icon until I looked into the source code here. |
Beta Was this translation helpful? Give feedback.
-
|
That's a great point. I'll update documentation to make this clearer. |
Beta Was this translation helpful? Give feedback.
At the point in time that your XPC helper tool performed the deserialization, did the
Authorizationinstance still exist in your main app? If not, then the authorization no longer exists in the Security Server.The output of
SMJobBlessUtil.py checkor codesign verification aren't relevant (yet) because unless I'm misunderstanding you haven't even been able to callLaunchdManager.bless(...)from your XPC helper server as you're unable to deserialize theAuthorizationinstance. It's the bless action which has code signing requirements, not anything related to authorization.