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

   ### Describe the feature
   
   Currently, `MODIFY_TABLE` is a coarse-grained privilege that bundles write 
data operations (INSERT, UPDATE, DELETE) and schema modification (ALTER TABLE) 
into a single permission. This makes it impossible to grant a user the ability 
to write data without also granting schema modification rights, or vice versa.
   
   We propose introducing finer-grained table privileges:
   
   - `INSERT_TABLE` — write rows to a table (INSERT, INSERT OVERWRITE)
   - `DELETE_TABLE` — delete rows from a table
   - `ALTER_TABLE` — modify table schema (ADD/DROP/RENAME COLUMN, partition 
changes, etc.)
   - `DROP_TABLE` — drop a table (currently only controllable via Ownership)
   
   ### Motivation
   
   In real-world data platforms, different user groups require different levels 
of access:
   
   - **ETL jobs / data pipelines**: need `INSERT_TABLE` to write data, but 
should NOT be allowed to alter table schemas
   - **Schema owners / data engineers**: need `ALTER_TABLE` for schema 
evolution, independent from data write access
   - **Compliance workflows**: `DELETE_TABLE` (e.g., GDPR right-to-erasure) 
requires explicit separate approval and should not be bundled with INSERT/UPDATE
   
   The current `MODIFY_TABLE` mapping in the JDBC authorization plugin 
translates to `SELECT + UPDATE + DELETE + INSERT + ALTER` — granting all of 
these together whenever a user needs write access. This violates the 
**principle of least privilege**.
   
   Industry-standard systems distinguish these operations:
   
   | System | Write Data | Modify Schema |
   |---|---|---|
   | Apache Ranger (Hive) | `UPDATE` / `WRITE` | `ALTER` |
   | Apache Hive native | `INSERT` | `ALTER` |
   | Trino | `INSERT` / `UPDATE` | `ALTER` |
   | MySQL / OceanBase | `INSERT` / `UPDATE` / `DELETE` | `ALTER` |
   | ClickHouse | `INSERT` | `ALTER TABLE` |
   
   Additionally, the internal EasyData client in `catalog-hive` already maps to 
granular permissions (`insert`, `update`, `delete`, `alter`) at the data source 
level — but Gravitino's public `Privilege.Name` enum cannot express this 
distinction, resulting in information loss at the abstraction layer.
   
   ### Describe the solution
   
   Add the following new `Privilege.Name` enum values:
   
   ```java
   INSERT_TABLE(0L, 1L << X),  // Write rows to a table
   DELETE_TABLE(0L, 1L << Y),  // Delete rows from a table
   ALTER_TABLE(0L, 1L << Z),   // Modify table schema
   DROP_TABLE(0L, 1L << W),    // Drop a table
   ```
   
   Keep `MODIFY_TABLE` unchanged for **full backward compatibility** — existing 
roles and integrations are not affected.
   
   Authorization plugin mapping updates:
   
   | New Privilege | Ranger (HadoopSQL) | JDBC (MySQL / OceanBase / Doris / 
ClickHouse) |
   |---|---|---|
   | `INSERT_TABLE` | `UPDATE`, `WRITE` | `INSERT` |
   | `DELETE_TABLE` | `UPDATE` | `DELETE` |
   | `ALTER_TABLE` | `ALTER` | `ALTER` |
   | `DROP_TABLE` | `DROP` | `DROP` |
   
   All new privileges support binding to: `Metalake`, `Catalog`, `Schema`, 
`Table` — consistent with existing `MODIFY_TABLE` and `SELECT_TABLE`.
   
   ### Additional context
   
   _No response_


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