roryqi opened a new issue, #13859:
URL: https://github.com/apache/gravitino/issues/13859
### Version
main branch
### Describe what's wrong
When a user can access a metadata object but cannot access some tags or
policies associated with it, the object association APIs filter those
associations from the response.
If all associated items are inaccessible, the APIs return the same empty
arrays used for an object with no associations:
```json
{"code": 0, "names": []}
```
The ambiguity exists for both name and detailed responses from:
- `GET /api/metalakes/{metalake}/objects/{type}/{fullName}/tags`
- `GET /api/metalakes/{metalake}/objects/{type}/{fullName}/policies`
A caller therefore cannot distinguish:
1. The object has no tags or policies.
2. The object has tags or policies, but the caller cannot access them.
This can incorrectly make a governed object appear untagged or without
policies.
The APIs should continue withholding inaccessible names and details, but
explicitly indicate that associations were omitted because of authorization.
Suggested response fields:
```json
{
"code": 0,
"names": [],
"hasInaccessibleTags": true
}
```
```json
{
"code": 0,
"names": [],
"hasInaccessiblePolicies": true
}
```
The detailed responses should expose the same state alongside `tags` or
`policies`.
Expected semantics:
- Empty list and `false`: the object has no associations.
- Empty list and `true`: all associations are inaccessible.
- Non-empty list and `true`: visible associations are returned, while others
are inaccessible.
- Non-empty list and `false`: all associations are visible.
Only the existence of inaccessible associations should be exposed. Their
names, count, details, and inheritance source should remain hidden.
### Error message and/or stacktrace
No error is returned. The request succeeds with HTTP 200 and an ambiguous
empty list:
```json
{"code": 0, "names": []}
```
### How to reproduce
1. Enable authorization.
2. Create a table.
3. Create a tag and a policy as an administrator and associate them with the
table.
4. Create another user who has `USE_CATALOG`, `USE_SCHEMA`, and
`SELECT_TABLE` for the table, but no tag or policy view/apply privilege.
5. As that user, call the object tag and policy list endpoints.
6. Observe that inaccessible associations are omitted and the response is
indistinguishable from an object with no associations.
### Additional context
This should be an additive, backward-compatible REST response change.
Existing clients may continue consuming the visible arrays, while clients aware
of the new fields can avoid presenting inaccessible associations as absent.
--
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]
