-
Notifications
You must be signed in to change notification settings - Fork 3.9k
binder: Introduce server authorization strategy v2 #12398
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -280,6 +280,67 @@ public BinderChannelBuilder preAuthorizeServers(boolean preAuthorize) { | |
| return this; | ||
| } | ||
|
|
||
| /** | ||
| * Specifies how and when to authorize a server against this Channel's {@link SecurityPolicy}. | ||
| * | ||
| * <p>This method selects the original "legacy" authorization strategy, which is no longer | ||
| * preferred for two reasons: First, the legacy strategy considers the UID of the server *process* | ||
| * we connect to. This is problematic for services using the `android:isolatedProcess` attribute, | ||
| * which runs them under a different "ephemeral" UID. This UID lacks all the privileges of the | ||
| * hosting app -- any non-trivial SecurityPolicy would fail to authorize it. Second, the legacy | ||
| * authorization strategy performs SecurityPolicy checks later in the connection handshake, which | ||
| * means the calling UID must be rechecked on every subsequent RPC. For these reasons, prefer | ||
| * {@link #useV2AuthStrategy} instead. | ||
| * | ||
| * <p>The server does not know which authorization strategy a client is using. Both strategies | ||
| * work with all versions of the grpc-binder server. | ||
| * | ||
| * <p>Callers need not specify an authorization strategy, but the default is unspecified and will | ||
| * eventually become {@link #useV2AuthStrategy()}. Clients that require the legacy strategy should | ||
| * configure it explicitly using this method. Eventually, however, legacy support will be | ||
| * deprecated and removed. | ||
| * | ||
| * @return this | ||
| */ | ||
| @ExperimentalApi("https://github.com/grpc/grpc-java/issues/12397") | ||
| public BinderChannelBuilder useLegacyAuthStrategy() { | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I was going to suggest (Feel free to use the same #12397 issue for this method; it'll at least be a hint to what's going on.) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. OK I marked that method experimental too. The new method can be experimental even if the legacy strategy behind it is the same as it ever was. I think BinderChannelBuilder should graduate out of experimental too. I can drive the stablization exercise if there is one. Looks like BinderServerBuilder's annotation was lifted in #9669. Do you have notes from the corresponding API review meeting? Perhaps BinderChannelBuilder was reviewed in that meeting too but just happened to not have any issues/comments. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The notes from the API review meeting were #9669 (review) . It seems it wasn't a goal to stabilize the client-side. In our 2022-09-01 meeting I see some limited discussion about the client-side, as it was noted it doesn't support ChannelCredentials and there was a suggestion of using it to pass in android.context.Context or using a global. But that's it. |
||
| transportFactoryBuilder.setUseLegacyAuthStrategy(true); | ||
| return this; | ||
| } | ||
|
|
||
| /** | ||
| * Specifies how and when to authorize a server against this Channel's {@link SecurityPolicy}. | ||
| * | ||
| * <p>This method selects the v2 authorization strategy. It improves on the original strategy | ||
| * ({@link #useLegacyAuthStrategy}), by considering the UID of the server *app* we connect to, | ||
| * rather than the server *process*. This allows clients to connect to services configured with | ||
| * the `android:isolatedProcess` attribute, which run with the same authority as the hosting app, | ||
| * but under a different "ephemeral" UID that any non-trivial SecurityPolicy would fail to | ||
| * authorize. | ||
| * | ||
| * <p>Furthermore, the v2 authorization strategy performs SecurityPolicy checks earlier in the | ||
| * connection handshake, which allows subsequent RPCs over that connection to proceed securely | ||
| * without further UID checks. For these reasons, clients should prefer the v2 strategy. | ||
| * | ||
| * <p>The server does not know which authorization strategy a client is using. Both strategies | ||
| * work with all versions of the grpc-binder server. | ||
| * | ||
| * <p>Callers need not specify an authorization strategy, but the default is unspecified and can | ||
| * change over time. Clients that require the v2 strategy should configure it explicitly using | ||
| * this method. Eventually, this strategy will become the default and legacy support will be | ||
| * removed. | ||
| * | ||
| * <p>If moving to the new authorization strategy causes a robolectric test to fail, ensure your | ||
| * fake Service component is registered with `ShadowPackageManager` using `addOrUpdateService()`. | ||
| * | ||
| * @return this | ||
| */ | ||
| @ExperimentalApi("https://github.com/grpc/grpc-java/issues/12397") | ||
| public BinderChannelBuilder useV2AuthStrategy() { | ||
| transportFactoryBuilder.setUseLegacyAuthStrategy(false); | ||
| return this; | ||
| } | ||
|
|
||
| @Override | ||
| public BinderChannelBuilder idleTimeout(long value, TimeUnit unit) { | ||
| checkState( | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.