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]

Reply via email to