nevzheng opened a new issue, #14253:
URL: https://github.com/apache/gravitino/issues/14253
### Version
main branch
### Describe what's wrong
A drop through the Iceberg REST server deletes the Gravitino entity, but
does not tell the
authorization plugins. `IcebergTableHookDispatcher#dropTable` (drop and
purge),
`IcebergNamespaceHookDispatcher#dropNamespace` and
`IcebergViewHookDispatcher#dropView` never call
`AuthorizationUtils`.
The same drops through the Gravitino REST API do:
`TableHookDispatcher#dropTable`/`purgeTable` and
`SchemaHookDispatcher#dropSchema` call
`authorizationPluginRemovePrivileges`, and
`ViewHookDispatcher#dropView` calls `notifyEntityNameIdMappingChange`.
So:
- **Plugin privileges outlive the object.** With a plugin such as Ranger,
the policies pushed for a
dropped table or namespace stay. A table later created under the same
name, through any path, is
covered by the old policies, although nobody granted them on the new table.
- **The name-id cache is not evicted.** Until the change poller catches up,
a recreated table, view or
namespace can resolve to the dropped object's id.
### Error message and/or stacktrace
None. The drop returns 204.
### How to reproduce
1. Serve an Iceberg catalog with `authorization-provider=ranger` through the
Iceberg REST server, with
`gravitino.authorization.enable=true`.
2. Grant `SELECT_TABLE` on `s1.t1` to a role of user `u1`. Ranger now has a
policy for `s1.t1`.
3. `DELETE /v1/{prefix}/namespaces/s1/tables/t1`.
Expected: the policy items for `s1.t1` are removed, as after the same drop
through
`DELETE /api/metalakes/{metalake}/catalogs/{catalog}/schemas/s1/tables/t1`.
Actual: the policy items stay. A new `s1.t1` created later is readable by
`u1`.
Dropping a namespace leaves the schema privileges in the same way.
### Additional context
Proposed fix: in the three Iceberg REST hook dispatchers, read the object
locations before the backend
drop and, after the drop and the existing entity cleanup, call
`authorizationPluginRemovePrivileges`
(tables and namespaces) or `notifyEntityNameIdMappingChange` (views, which
carry no plugin
privileges), as the core hooks do. A failed backend drop throws before these
calls.
--
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]