roryqi opened a new issue, #14723:
URL: https://github.com/apache/gravitino/issues/14723
### Version
main branch, commit `ebf08d6659b111964e84665557485995e808c9f5`.
### Describe what's wrong
Several role and privilege operations still have inconsistent validation or
audit behavior:
| Case | Current behavior | Expected behavior |
| --- | --- | --- |
| Grant a privilege already held under its deprecated alias, with the same
condition | 400 claiming that the conditions differ | 200 with no duplicate
privilege; opposite conditions must still be rejected |
| Grant a role to an existing user or group | The new relation copies the
principal's creator and creation time | The relation records who granted the
role and when; revoke followed by regrant creates fresh assignment audit
information |
| Grant/revoke privileges or set an owner using an unknown object type or
malformed full name | Invalid input can become a generic 500 during
authorization | 400 describing the invalid type or name |
| Create a role or grant privileges on FILESET, MODEL or TOPIC objects in a
catalog without the corresponding operations | The existence probe can
propagate UnsupportedOperationException as 501 | A client error consistent with
the existing TABLE handling |
### Error message and/or stacktrace
```text
Doesn't support duplicated privilege name CREATE_MODEL with different
condition
Authorization failed due to system internal error. Please contact
administrator.
Catalog does not support fileset operations
```
### How to reproduce
Enable authorization and use an authorized administrator. The following
checks target public APIs or the relational store:
1. Create an empty role. Grant `CREATE_MODEL ALLOW` on the metalake, then
grant `REGISTER_MODEL ALLOW` on the same object through `PUT
/api/metalakes/{metalake}/permissions/roles/{role}/metalake/{metalake}/grant`.
Repeat in reverse order and with `CREATE_MODEL_VERSION` / `LINK_MODEL_VERSION`.
Repeating the exact same name is an accepted control.
2. Create a user and a group at time T0. Later create and grant a role at
T1. Inspect the newly inserted user-role and group-role relation audit
information: `createTime` is T0 rather than T1. Revoke and regrant, and inspect
the new relation again. Use different callers for principal creation and
granting to check `creator` as well.
3. Send a valid privilege body to `PUT
/api/metalakes/{metalake}/permissions/roles/{role}/{type}/{fullName}/grant` and
`/revoke`, using `type=nosuchtype`, or `type=table` with
`fullName=catalog.schema`. Also call `PUT
/api/metalakes/{metalake}/owners/nosuchtype/catalog.schema.table` with a valid
owner body. Test malformed owner full names with an ordinary metalake member
too, since the metalake owner short-circuits part of authorization.
4. In an existing relational catalog and schema, create roles with securable
objects of type `FILESET`, `MODEL` and `TOPIC`, using matching privileges such
as `READ_FILESET`, `USE_MODEL` and `CONSUME_TOPIC`. Repeat with privilege
grants to an existing role. The catalog does not implement those object
operations.
### Additional context
Source inspection identifies these remaining paths; no deployed-server
reproduction was performed against the commit above:
- Alias handling: `PermissionManager.updateGrantedSecurableObject`
deduplicates exact privileges before
`AuthorizationUtils.checkDuplicatedNamePrivilege` canonicalizes names and
rejects duplicates without comparing conditions.
- Assignment audit: `POConverters.initializeUserRoleRelsPOWithVersion` and
`initializeGroupRoleRelsPOWithVersion` serialize the principal's audit into new
relation rows. Grant operations preserve the principal's original creator and
creation time.
- Metadata paths: privilege grant/revoke and owner-set parameters lack
`@AuthorizationObjectType` / `@AuthorizationFullName`. Their authorizer methods
parse raw values, bypassing the validation added for annotated parameters.
- Catalog capability: FILESET/MODEL/TOPIC existence probes lack the
capability check now present in `TableOperationDispatcher.tableExists`.
Already resolved cases are excluded: dotted role creation (#14443, fixed by
#14519), invalid load-table privilege queries (#14610, fixed by #14612), and
the TABLE existence-probe case (#14578, fixed by #14584).
--
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]
