Principal、Privilege 、Policy and role support Spark SQL management.

### Is your feature request related to a problem? Please describe.

By combining Spark SQL and Polaris, and designing a set of Spark SQL syntax to manage Principal, Privilege, Policy and Role, it will be much more convenient to use.

The following is the SQL syntax designed for me by Gemini. As a reference:

## 🧭 Syntax Architecture Overview

In Apache Polaris, access control is structured around a few core entities:
- **Principal**: The identity performing the action (e.g., a user or service).
- **Role**: The grouping mechanism. Polaris distinguishes between *Principal Roles* (assigned to principals) and *Catalog Roles* (assigned to securable resources).
- **Privilege**: The specific action allowed on a resource (e.g., `TABLE_READ`, `VIEW_CREATE`).
- **Policy**: The binding logic or rule set that governs how roles, principals, and conditions interact.

Below is a summary of the proposed SQL commands for managing these entities.

| **Category** | **SQL Command Template** | **Description** |
|---|---|---|
| **Principal Management** | `CREATE / DROP / SHOW PRINCIPAL` | Manages users and service identities. |
| **Role Management** | `CREATE / DROP / SHOW ROLE` | Manages Catalog and Principal roles. |
| **Privilege Management** | `GRANT / REVOKE ON ` | Controls access to catalogs, namespaces, and tables. |
| **Policy & Assignment** | `GRANT ROLE TO` or `CREATE POLICY` | Binds principals to roles, optionally with conditions. |

---

## 🔍 Detailed SQL Syntax Design

### 1. Principal Management
Principals represent the "who" in your security model. They can be users or external service clients.

```sql
-- Create a new principal with optional credentials or properties
CREATE PRINCIPAL [IF NOT EXISTS]
TYPE { USER | SERVICE }
[ WITH PROPERTIES ( 'key1'='value1', 'key2'='value2' ) ];

-- Drop an existing principal
DROP PRINCIPAL [IF EXISTS] ;

-- List or describe principals
SHOW PRINCIPALS [ LIKE 'pattern' ];
DESCRIBE PRINCIPAL ;
```

### 2. Role Management
Polaris utilizes roles to decouple identities from direct resource privileges. We support both **Principal Roles** (assigned to users) and **Catalog Roles** (assigned to resources), as well as nesting them.

```sql
-- Create roles
CREATE [PRINCIPAL | CATALOG] ROLE [IF NOT EXISTS] ;

-- Drop roles
DROP ROLE [IF EXISTS] ;

-- Grant a Catalog Role to a Principal Role (Role Inheritance / Mapping)
GRANT ROLE TO ROLE ;
REVOKE ROLE FROM ROLE ;

-- List roles
SHOW ROLES [ LIKE 'pattern' ];
```

### 3. Privilege Management
Privileges define the "what" and "where". They grant catalog-level or table-level access to **Catalog Roles**.

```sql
-- Grant privileges on a securable resource to a Catalog Role
GRANT [, ...]
ON { CATALOG | NAMESPACE | TABLE | VIEW }
TO ROLE ;

-- Revoke privileges
REVOKE [, ...]
ON { CATALOG | NAMESPACE | TABLE | VIEW }
FROM ROLE ;

-- Show granted privileges
SHOW GRANTS ON ROLE ;
SHOW GRANTS ON { CATALOG | NAMESPACE | TABLE } ;
```
*Note: `` includes Polaris-native privileges such as `CATALOG_MANAGE_METADATA`, `NAMESPACE_READ`, `TABLE_WRITE`, etc.*

### 4. Policy & Assignment Management
Policies represent the binding layer. While basic RBAC uses simple grants, advanced deployments benefit from explicit policy objects to handle conditional access (e.g., time-bound access or row/column filters).

```sql
-- Standard Assignment: Bind a Principal Role to a Principal
GRANT ROLE TO PRINCIPAL ;
REVOKE ROLE FROM PRINCIPAL ;

-- Advanced Policy: Create a conditional policy rule
CREATE POLICY [IF NOT EXISTS]
FOR ROLE
TO PRINCIPAL
[ WITH ROW FILTER ON ]
[ WITH COLUMN MASKING ( USING ) ]
[ EFFECTIVE FROM '' TO '' ];

-- Drop a policy
DROP POLICY [IF EXISTS] ;

-- Show policies
SHOW POLICIES [ ON TABLE | FOR PRINCIPAL ];
```

---

## 💡 Practical Example Workflow

Here is how these custom SQL statements flow together in a real-world scenario where you want to grant an ETL service account read/write access to a specific namespace.

```sql
-- Step 1: Create the Principal (the service account)
CREATE PRINCIPAL etl_service_principal TYPE SERVICE
WITH PROPERTIES ('client_id'='etl_01', 'department'='data_platform');

-- Step 2: Create the Principal Role and assign it to the Principal
CREATE PRINCIPAL ROLE etl_executor_role;
GRANT ROLE etl_executor_role TO PRINCIPAL etl_service_principal;

-- Step 3: Create the Catalog Role and grant resource privileges to it
CREATE CATALOG ROLE sales_rw_role;
GRANT NAMESPACE_READ, TABLE_WRITE ON NAMESPACE main_catalog.sales_db TO ROLE sales_rw_role;

-- Step 4: Link the Catalog Role to the Principal Role
GRANT ROLE sales_rw_role TO ROLE etl_executor_role;

-- Step 5: (Optional) Apply a time-bound Policy for strict governance
CREATE POLICY temporary_etl_access_policy
FOR ROLE etl_executor_role
TO PRINCIPAL etl_service_principal
EFFECTIVE FROM '2026-08-12 00:00:00' TO '2026-12-31 23:59:59';
```

No files, tests, or entry points are identified in the issue. Start by reviewing the existing Polaris authorization model and Spark SQL integration, then compare the proposed principal, role, privilege, and policy commands with current capabilities. Done requires an agreed scope, implementation, and tests for the supported SQL syntax.

Written by the indexing model from the issue text.