markhoerth commented on issue #12729:
URL: https://github.com/apache/gravitino/issues/12729#issuecomment-5471534881
Reproduced on a deployed Enterprise install with
`gravitino.authorization.enable = true` and the OAuth authenticator.
Both calls below are made by the same authenticated user (`mark`, OIDC
password grant, `preferred_username` principal), against the same metalake,
with no privileges granted.
Metadata object tags, an intercepted class:
```
GET /api/metalakes/authzproof/objects/table/c1.s1.t1/tags
{"code":1008,"type":"ForbiddenException",
"message":"Current user mark doesn't exist in the metalake authzproof, you
should add the user to the metalake first"}
```
Views, an unintercepted class:
```
GET /api/metalakes/authzproof/catalogs/c1/schemas/s1/views
{"code":1003,"type":"NoSuchCatalogException",
"message":"Failed to operate view(s) operation [LIST] under schema [s1],
reason [Catalog authzproof.c1 does not exist]"}
```
The tags request is refused by `MetadataAuthorizationMethodInterceptor`
before any lookup. The views request passes the authorization stage entirely
and executes the catalog lookup, returning a result that depends on the state
of a metalake the caller has no rights in.
This is the runtime confirmation on Enterprise. `ViewOperations` is absent
from the class allowlist in
`GravitinoInterceptionService.getDescriptorFilter()`, and the behaviour above
is the consequence.
Scope note: this demonstrates that view operations are not
privilege-checked. It does not by itself demonstrate the disclosure of view
contents, which would require a populated metalake the caller has no access to.
--
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]
