binder: A Channel might check its SecurityPolicy even after declaring termination
Los mantenedores suelen responder en 2 días
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 42/100
- Tipo de issue
- Error
- Claridad
- Necesita aclaración
- Estado de actividad
- Tranquilo
- Stack tecnológico
- java
- Área
- backend-api-design, security
Línea de trabajo
Empieza leyendo la ruta de AsyncSecurityPolicy de BinderClientTransport, especialmente checkServerAuthorizationAsync(), checkAuthorization(), shutdownNow() y el callback transportTerminated(). Sigue el envío a offloadExecutor y las transiciones de estado para determinar si la autorización puede ejecutarse después de la terminación; se considera terminado cuando la garantía del ciclo de vida está establecida y cubierta por una prueba de regresión o por un razonamiento claramente documentado.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
What version of gRPC-Java are you using?
master/HEAD on any version of Android
What did you expect to see?
Some reasoning/guarantee that a Channel will no longer call into its SecurityPolicy after it declares termination.
Steps to reproduce the bug
One of many ways is to call ManagedChannel.shutdownNow() while it's establishing a new connection.
Analysis
When using AsyncSecurityPolicy, BinderClientTransport calls checkServerAuthorizationAsync() while holding its this lock and only after carefully checking that it's not in state SHUTDOWN or SHUTDOWN_TERMINATED. This is safe because clientTransportListener.transportTerminated() is only called after transitioning into those states while holding the same lock. (We do this on the assumption that AsyncSecurityPolicy checks don't block)
However, when using an ordinary blocking SecurityPolicy, checkServerAuthorizationAsync() is implemented by submit()ing this presumably blocking work to offloadExecutor. We first do the same state checks, but because we release the this lock, the transport could shutdown and declare termination after this submission but before the offload executor actually calls checkAuthorization().
- Lenguaje dominante
- Java
- Estrellas
- 12.1k
- Forks
- 4k
- Merge medio
- 2 d 3 h
- PR fusionados (30 d)
- 30
Preparar el entorno
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de grpc/grpc-java
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
grpc/grpc-java#13052 · 4 comentarios ·
Los mantenedores suelen responder en 2 días
-
Support of `dns:name` URIsAbiertodocs enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
grpc/grpc-java#10824 · 8 comentarios ·
Los mantenedores suelen responder en 2 días
-
Dificultad 4/5 3-5 días Aptitud para principiantes 70/100
Los mantenedores suelen responder en 2 días
-
Dificultad 3/5 1-2 días Aptitud para principiantes 65/100
Los mantenedores suelen responder en 2 días
Todos los issues de grpc/grpc-java
Issues similares
-
P2 testing
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
Los mantenedores suelen responder en 1 día
-
area/core kind/bug status/triage team/core-shared
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
checkstyle/checkstyle#21755 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
spring-projects/spring-integration#11495 ·
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
Los mantenedores suelen responder en 1 día