nevzheng opened a new issue, #14266:
URL: https://github.com/apache/gravitino/issues/14266

   ### Version
   
   main branch
   
   ### Describe what's wrong
   
   `DELETE /api/metalakes/{metalake}?force=true` drops each child catalog in
   `MetalakeManager#dropCatalogsUnderMetalake` by calling 
`CatalogManager#dropCatalog` directly. That is
   the bottom of the catalog chain (`CatalogEventDispatcher -> 
CatalogNormalizeDispatcher ->
   CatalogHookDispatcher -> CatalogManager`), so for those catalogs:
   
   - no `DropCatalogPreEvent`, `DropCatalogEvent` or `DropCatalogFailureEvent` 
is sent to the event bus,
     so event listeners and audit never see the catalog drops;
   - `CatalogHookDispatcher#dropCatalog` never runs, so the catalogs are never 
removed from their
     authorization plugin (`AuthorizationUtils.removeCatalogPrivileges`). The 
drop closes each catalog's
     plugin, so nothing can clean those privileges later.
   
   Force-dropping each catalog and then the metalake does all of this. A single 
forced metalake drop does
   none of it. If catalogs with the same names are later created on the same 
Ranger service, they pick up
   the old privileges.
   
   ### Error message and/or stacktrace
   
   None. The metalake and its catalogs are removed.
   
   ### How to reproduce
   
   1. Enable authorization and register an event listener that logs 
`DropCatalogEvent`.
   2. In metalake `m`, create a Hive catalog `c` with 
`authorization-provider=ranger` (`HadoopSQL`), and
      grant a role with `USE_CATALOG` on `c` to a user.
   3. `DELETE /api/metalakes/m?force=true`.
   
   Expected: `DropCatalogPreEvent` and `DropCatalogEvent` for `m.c`, and the 
Ranger policy items for `c`
   removed, as after `DELETE /api/metalakes/m/catalogs/c?force=true`.
   Actual: only the metalake drop events, and the Ranger policy items for `c` 
are unchanged.
   
   ### Additional context
   
   Proposed fix: let `MetalakeManager` drop the child catalogs through the 
public catalog dispatcher.
   `GravitinoEnv` builds that chain after the metalake manager, so it has to be 
passed lazily. If one
   catalog drop fails partway, the metalake must stay in its previous state, as 
the current code already
   does by disabling again a metalake it enabled for the drop.
   


-- 
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