[FEATURE] Split MODIFY_TABLE privilege into INSERT_TABLE and ALTER_TABLE for finer-grained access control

[JoegenUSTC]

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:

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