feat(mac): sod mandatory and mac[manual-only]

.github/scripts/check_enum_append_only.py

@@ -61,6 +61,7 @@ def check_enum_values_preserved(old_list, new_list, ignore_list):
     "EQueueType": {"QUEUE_MAX"},
     "EDriverType": {"DRIVER_MAX"},
     "EGrantState": {"GRANT_STATE_MAX"},
+    "EOperType": {"MND_OPER_MAX"},
     "TSFormatKeywordId": {"*"},
 }
 

docs/en/14-reference/03-taos-sql/61-grant.md

@@ -279,6 +279,176 @@ SET USER AUDIT INFORMATION
 READ INFORMATION_SCHEMA AUDIT
 ```
 
+### Mandatory Separation of Duties (SoD Mandatory)
+
+#### Availability
+
+Available from 3.4.1.5 (Enterprise Edition).
+
+Mandatory Separation of Duties (SoD Mandatory) further enforces the three-power separation model: once activated, the system continuously verifies that each of the three security roles has at least one active and enabled holder, prohibits granting any two of the three roles to the same user, and automatically disables the root account.
+
+#### Enabling SoD Mandatory
+
+```sql
+-- Enable mandatory separation of duties (executor must hold PRIV_SECURITY_POLICY_ALTER privilege or the SYSSEC role)
+ALTER CLUSTER 'sod' 'mandatory';
+-- Or using the full name
+ALTER CLUSTER 'separation_of_duties' 'mandatory';
+```
+
+**Pre-conditions:** Before execution, the system must already have:
+
+- At least one enabled non-root user holding the SYSDBA role
+- At least one enabled non-root user holding the SYSSEC role
+- At least one enabled non-root user holding the SYSAUDIT role
+
+Otherwise an error is returned (example):
+
+```text
+No enabled non-root user with SYSDBA role found to satisfy SoD policy
+```
+
+#### Behavior After SoD Mandatory Activation
+
+| Behavior | Description |
+|----------|-------------|
+| root account automatically disabled | After activation, root cannot be used for daily operations |
+| Continuous three-power verification | Any operation that would leave a role without a holder (DROP USER, REVOKE ROLE, disable user) returns an error |
+| Cannot be deactivated | SoD Mandatory cannot be revoked once activated |
+| Idempotent re-activation | Re-executing when already active has no side effects |
+
+**Check SoD status:**
+
+```sql
+SELECT name, mode FROM information_schema.ins_security_policies WHERE name='SoD';
+-- Or
+SHOW SECURITY_POLICIES;
+```
+
+---
+
+### Mandatory Access Control (MAC)
+
+#### Availability
+
+Available from 3.4.1.5 (Enterprise Edition).
+
+Mandatory Access Control (MAC) enforces the **No-Read-Up (NRU)** and **No-Write-Down (NWD)** rules by assigning **security levels** to users and database objects, preventing high-sensitivity data from reaching low-clearance users.
+
+#### Security Level Definitions
+
+Security levels range from 0 to 4 (integers; higher values indicate greater sensitivity). Users are defined with a range `[min_level, max_level]`; database objects are defined with a single level.
+
+| Level | Meaning |
+|-------|---------|
+| 0 | Public |
+| 1 | Internal |
+| 2 | Confidential |
+| 3 | Secret |
+| 4 | Top Secret |
+
+#### Setting Security Levels
+
+```sql
+-- Set user security level (requires PRIV_SECURITY_POLICY_ALTER privilege, i.e. SYSSEC role or equivalent)
+ALTER USER user_name SECURITY_LEVEL min_level, max_level;
+
+-- Set database security level
+ALTER DATABASE db_name SECURITY_LEVEL level;
+
+-- Set super table security level (must not be lower than the DB's level)
+ALTER TABLE db_name.stb_name SECURITY_LEVEL level;
+
+-- Setting SECURITY_LEVEL at CREATE USER time requires PRIV_SECURITY_POLICY_ALTER privilege.
+-- SYSDBA does not hold this privilege by default, but it can be explicitly granted:
+--   GRANT PRIV_SECURITY_POLICY_ALTER TO dba_user;
+-- Under the recommended SoD division of duties: SYSDBA creates the user;
+-- SYSSEC separately executes ALTER USER ... SECURITY_LEVEL.
+```
+
+**Role Floor Constraint:**
+
+| Role | Min minSecLevel required | Min maxSecLevel required |
+|------|--------------------------|---------------------------|
+| SYSDBA | 0 | 3 |
+| SYSSEC | 4 | 4 |
+| SYSAUDIT | 4 | 4 |
+| SYSAUDIT_LOG | 4 | 4 |
+| Direct `PRIV_SECURITY_POLICY_ALTER` holder (not via role) | No constraint | 4 |
+| Regular user | No constraint (default `[0,1]`) | No constraint |
+
+- When MAC is **not active**: GRANT role and ALTER USER security_level do not check the role floor.
+- When MAC is **active**: Both `minSecLevel` and `maxSecLevel` must satisfy the role's floor constraints before GRANT succeeds, and ALTER USER security_level cannot lower either value below the current role floor. Additionally, users who directly hold `PRIV_SECURITY_POLICY_ALTER` (not via a role) must keep `maxSecLevel = 4`.
+- **Trusted principals**: Users holding `PRIV_SECURITY_LEVEL_ALTER` (i.e. the SYSSEC role or equivalent) bypass the escalation-prevention check and can assign any security level. This privilege is specifically designed for data synchronization tools such as taosX. When granted, it is strongly recommended to restrict the account's access using an IP Whitelist to mitigate security risks. Beyond synchronization scenarios, granting the PRIV_SECURITY_LEVEL_ALTER privilege to regular users is highly discouraged to maintain the integrity of the Mandatory Access Control (MAC) policy.
+
+#### Enabling MAC
+
+```sql
+-- Enable mandatory access control (executor must hold PRIV_SECURITY_POLICY_ALTER privilege or the SYSSEC role)
+ALTER CLUSTER 'MAC' 'mandatory';
+-- Or using the full name
+ALTER CLUSTER 'mandatory_access_control' 'mandatory';
+```
+
+**Activation Pre-activation Check:** Before activation, the system scans **all users who hold any system role** (SYSSEC, SYSAUDIT, SYSAUDIT_LOG, SYSDBA) and **all users who directly hold `PRIV_SECURITY_POLICY_ALTER`** (including disabled users). For each such user, `minSecLevel` and `maxSecLevel` are checked against the applicable constraints. The scan stops at the first failing user and returns an error containing that user's name, for example:
+
+```text
+Cannot enable MAC: user 'u_sec1' maxSecLevel(1) < required maxFloor(4) (role constraint). Please ALTER USER u_sec1 SECURITY_LEVEL <4,4> to satisfy constraints first.
+```
+
+> **Note**: If multiple users block activation, only one is reported per attempt. After fixing the reported user, retry — a different blocking user may then be reported.
+
+**Troubleshooting:**
+
+```sql
+-- Find system-role holders and check their security levels
+SELECT name, sec_levels FROM information_schema.ins_users;
+
+-- Option 1: Raise the blocking user's security level to satisfy role floor
+-- For SYSSEC/SYSAUDIT/SYSAUDIT_LOG (floor=[4,4]):
+ALTER USER u_sec1 SECURITY_LEVEL 4,4;
+-- For SYSDBA (floor=[0,3]):
+ALTER USER u_dba1 SECURITY_LEVEL 0,3;
+
+-- Option 2: Revoke the system role so the user no longer triggers the floor check
+REVOKE ROLE `SYSSEC` FROM u_sec1;
+```
+
+> **Important**: REVOKE role does **not** automatically reset the user's `security_level`. After revoking a system role, the user retains the previously assigned `security_level`. Use `ALTER USER ... SECURITY_LEVEL` to adjust it manually if needed.
+
+#### MAC Access Control Rules
+
+After MAC is activated, all data access is additionally subject to the following rules (evaluated after DAC permission checks):
+
+| Rule | Description | Notes |
+|------|-------------|-------|
+| NRU (No-Read-Up) | Allowed when user maxSecLevel **≥** object secLevel | High-sensitivity data cannot be read by low-clearance users |
+| NWD (No-Write-Down) | Allowed when user minSecLevel **≤** object secLevel | High-clearance users cannot write to low-sensitivity objects |
+
+- Subtables inherit the secLevel of their parent super table; regular tables inherit the secLevel of their database.
+- A user with security_level `[0, 4]` (i.e. minSecLevel=0, maxSecLevel=4) hits the **fast path** (no metadata lookup required) with zero performance impact.
+
+**Check MAC status:**
+
+```sql
+SELECT name, mode, operator, activate_time
+FROM information_schema.ins_security_policies
+WHERE name='MAC';
+```
+
+#### MAC Error Codes
+
+| Error Code | Trigger Scenario |
+|------------|-----------------|
+| `TSDB_CODE_MAC_INSUFFICIENT_LEVEL` | SELECT rejected because user maxSecLevel is below the object's secLevel (NRU violation); or CREATE/ALTER USER SECURITY_LEVEL rejected because the target maxSecLevel exceeds the operator's own maxSecLevel (MAC mandatory and operator is not a trusted principal) |
+| `TSDB_CODE_MAC_NO_WRITE_DOWN` | INSERT rejected because user minSecLevel is above the object's secLevel (NWD violation) |
+| `TSDB_CODE_MAC_SEC_LEVEL_CONFLICTS_ROLE` | When MAC is active: GRANT role to a user whose `minSecLevel` or `maxSecLevel` does not satisfy that role's floor constraints; or ALTER USER SECURITY_LEVEL would lower `minSecLevel` or `maxSecLevel` below the floor imposed by a role the user already holds |
+| `TSDB_CODE_MAC_OBJ_LEVEL_BELOW_DB` | Super table secLevel set lower than the database's secLevel (objects may not be below the DB container level) |
+| `TSDB_CODE_MAC_ACTIVATION_PREFLIGHT_FAIL` | MAC activation Pre-activation check failed: a privilege or system-role holder's `minSecLevel` or `maxSecLevel` does not satisfy its constraints |
+| `TSDB_CODE_MAC_INVALID_LEVEL` | secLevel value outside the valid range [0,4] |
+
+---
+
 ### Role Management
 
 #### Creating Roles
@@ -908,6 +1078,8 @@ taos> show role privileges;
 1. **Immediately Separate Three Permissions**: After initialization, assign SYSDBA/SYSSEC/SYSAUDIT to different users
 2. **Disable root for Daily Operations**: After configuration completion, no longer use root for daily maintenance
 3. **Use Roles to Simplify Permissions**: Create common roles and grant them to users
+4. **Enable SoD Mandatory**: After separating the three powers, execute `ALTER CLUSTER 'sod' 'mandatory'` to enforce separation of duties; after activation, root is automatically disabled and the system continuously verifies that all three roles have active holders
+5. **Enable MAC** (optional): Execute `ALTER CLUSTER 'MAC' 'mandatory'` first. If errors occur, adjust users' security_level according to the prompts. Once activated, MAC mode cannot be disabled.
 
 **Example - Create Read-Only Analysis Role:**
 
@@ -946,15 +1118,17 @@ GRANT ROLE `SYSAUDIT_LOG` TO audit_logger;
 
 ## Compatibility and Upgrades
 
-| Feature | 3.3.x.y- | 3.4.0.0+ |
-|---------|---------|----------|
-| CREATE/ALTER/DROP USER | ✓ | ✓ |
-| GRANT/REVOKE READ/WRITE | ✓ | ✗ |
-| View/Subscription Permissions | ✓ | ✓ |
-| Role Management | ✗ | ✓ |
-| Separation of Three Powers | ✗ | ✓ |
-| Fine-grained Permissions | ✗ | ✓ |
-| Audit Database | ✗ | ✓ |
+| Feature | 3.3.x.y- | 3.4.0.0+ | 3.4.1.5+ |
+|---------|---------|----------|----------|
+| CREATE/ALTER/DROP USER | ✓ | ✓ | ✓ |
+| GRANT/REVOKE READ/WRITE | ✓ | ✗ | ✗ |
+| View/Subscription Permissions | ✓ | ✓ | ✓ |
+| Role Management | ✗ | ✓ | ✓ |
+| Separation of Three Powers | ✗ | ✓ | ✓ |
+| Mandatory Separation of Duties (SoD Mandatory) | ✗ | ✗ | ✓ (Enterprise) |
+| Mandatory Access Control (MAC) | ✗ | ✗ | ✓ (Enterprise) |
+| Fine-grained Permissions | ✗ | ✓ | ✓ |
+| Audit Database | ✗ | ✓ | ✓ |
 
 **Upgrade Notes:**
 

docs/en/14-reference/09-error-code.md

@@ -117,6 +117,14 @@ Below are the business error codes for each module.
 | 0x80000140 | Edition not compatible            | Edition incompatibility between nodes                        | Check editions(enterprise or community) of all nodes (including server and client), ensure node editions are consistent or compatible |
 | 0x80000141 | Invalid signature                 | Message signature is invalid or mismatch                     | Check if client and server are using the same signature algorithm |
 | 0x80000142 | External window subquery must return time-ordered rows | The EXTERNAL WINDOW subquery result is not sorted by time | Ensure the EXTERNAL WINDOW subquery returns time-ordered rows, add ORDER BY ts to the subquery if necessary |
+| 0x80000143 | Insufficient user security level for the operation | User's max security level is lower than the object's security level (NRU violation) | Use a user account with a higher security level, or lower the object's security level |
+| 0x80000144 | Object level below database security level | A sub-object's security level is lower than the database's security level | Raise the sub-object's level to at least the database level before upgrading the database |
+| 0x80000145 | Object level below user's minimum write level | The target object's security level is below the user's minimum allowed write level | Adjust the user's security_level range or the object's security level |
+| 0x80000146 | Object level above user's maximum read level | The target object's security level is above the user's maximum allowed read level | Adjust the user's security_level range or the object's security level |
+| 0x80000147 | Security level out of valid range [0-4] | The specified security level is not within the allowed range | Use a security level between 0 and 4 |
+| 0x80000148 | User security level is too high to write (No-Write-Down) | User's minimum security level is higher than the object's level (NWD violation) | Use a user account with a lower minimum security level, or raise the object's security level |
+| 0x80000149 | Security level conflicts with user's role constraints | The specified security level range does not meet the minimum floor required by the user's assigned roles | Adjust the security level to satisfy role constraints (e.g., SYSSEC requires min >= 4) |
+| 0x8000014A | Cannot enable MAC: preflight check failed | A user with a security policy role has an insufficient security level for MAC activation | Upgrade the user's security_level before enabling MAC |
 
 #### tsc
 
@@ -294,6 +302,9 @@ Below are the business error codes for each module.
 | 0x800004E3 | Encryption algorithm type not match                          | Does not exist                                               | Confirm if the operation is correct                          |
 | 0x800004E4 | Invalid encryption algorithm format                          | Input algorithm id is empty                                               | Confirm if the operation is correct                          |
 | 0x800004E5 | Encryption algorithm in use                                  | Still in use                                                  | Remove all object which use this algorithm                          |
+| 0x800004FB | No enabled non-root user with SYSSEC role found                       | SoD policy requires an enabled user with SYSSEC role         | Create or enable a user with SYSSEC role before activating SoD |
+| 0x800004FC | No enabled non-root user with SYSAUDIT role found                     | SoD policy requires an enabled user with SYSAUDIT role       | Create or enable a user with SYSAUDIT role before activating SoD |
+| 0x800004FD | Operation not allowed in current SoD status                  | The operation is restricted under the current Separation-of-Duty mode | Check if SoD is mandatory and use the appropriate role user for this operation |
 
 #### Bnode