sunyuhan1998 commented on code in PR #10895:
URL: https://github.com/apache/gravitino/pull/10895#discussion_r3212901598
##########
lance/lance-rest-server/src/main/java/org/apache/gravitino/lance/service/rest/LanceTableOperations.java:
##########
@@ -90,16 +96,37 @@ public Response describeTable(
DescribeTableRequest request) {
try {
validateDescribeTableRequest(request);
+ boolean vendCredentials =
+ request.getVendCredentials() == null ||
Boolean.TRUE.equals(request.getVendCredentials());
+ CredentialPrivilege privilege =
+ vendCredentials ? getCredentialPrivilege(tableId, delimiter) : null;
DescribeTableResponse response =
lanceNamespace
.asTableOps()
- .describeTable(tableId, delimiter,
Optional.ofNullable(request.getVersion()));
+ .describeTable(
+ tableId, delimiter,
Optional.ofNullable(request.getVersion()), privilege);
return Response.ok(response).build();
} catch (Exception e) {
return LanceExceptionMapper.toRESTResponse(tableId, e);
}
}
+ private CredentialPrivilege getCredentialPrivilege(String tableId, String
delimiter) {
+ String[] parts = tableId.split(Pattern.quote(delimiter));
+ if (parts.length != 3) {
+ return CredentialPrivilege.READ;
Review Comment:
The `parts` should always have length 3 (catalog/schema/table) in normal
flow. When it doesn't, using `READ` is a conservative safe default — it's
better to under-provision than over-provision credentials. That said, this
branch should never be reached in practice since upstream validation already
enforces the 3-level structure. Would it be better to throw an explicit
exception here instead?
##########
lance/lance-rest-server/src/main/java/org/apache/gravitino/lance/service/rest/LanceTableOperations.java:
##########
@@ -90,16 +96,37 @@ public Response describeTable(
DescribeTableRequest request) {
try {
validateDescribeTableRequest(request);
+ boolean vendCredentials =
+ request.getVendCredentials() == null ||
Boolean.TRUE.equals(request.getVendCredentials());
+ CredentialPrivilege privilege =
+ vendCredentials ? getCredentialPrivilege(tableId, delimiter) : null;
DescribeTableResponse response =
lanceNamespace
.asTableOps()
- .describeTable(tableId, delimiter,
Optional.ofNullable(request.getVersion()));
+ .describeTable(
+ tableId, delimiter,
Optional.ofNullable(request.getVersion()), privilege);
return Response.ok(response).build();
} catch (Exception e) {
return LanceExceptionMapper.toRESTResponse(tableId, e);
}
}
+ private CredentialPrivilege getCredentialPrivilege(String tableId, String
delimiter) {
+ String[] parts = tableId.split(Pattern.quote(delimiter));
+ if (parts.length != 3) {
+ return CredentialPrivilege.READ;
+ }
+
+ String metalake = lanceNamespace.config().getGravitinoMetalake();
+ NameIdentifier identifier = NameIdentifier.of(metalake, parts[0],
parts[1], parts[2]);
+ boolean writable =
+ MetadataAuthzHelper.checkAccess(
+ identifier,
+ Entity.EntityType.TABLE,
+
AuthorizationExpressionConstants.FILTER_MODIFY_TABLE_AUTHORIZATION_EXPRESSION);
Review Comment:
Yes, `MetadataAuthzHelper.checkPermission()` checks whether the current
authenticated user has write privilege on the table. The current user is
obtained from the Gravitino authentication context — when the request arrives,
the identity is already established and bound to the thread context. During
credential generation, `CatalogCredentialManager` calls
`PrincipalUtils.getCurrentUserName()` to retrieve the authenticated username
and generates credentials scoped to that user's permissions.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
