Fix protocol permissions to use table namespaces instead of separate roles

Co-authored-by: joocer <[email protected]>

Author: Copilot

testdata/PERMISSIONS_README.md

@@ -14,74 +14,92 @@ The `permissions.json` file contains one JSON object per line, each defining a p
 - **permission**: The type of permission (currently only "READ" is supported)
 - **table**: A pattern (supporting wildcards) that matches table names
 
-## Protocol Prefix Permissions
+## Protocol Prefixes as Table Namespaces
 
-Starting with the wildcard support for cloud storage paths, you can now control access to different storage protocols using permission patterns:
+Protocol prefixes (`file://`, `gs://`, `s3://`) are treated as table namespaces, just like dataset namespaces (e.g., `opteryx.*`). You can control access to these protocols by adding permission entries for specific roles.
 
-### File System Access
+### Example Configurations
+
+#### Restrict a Role to Only Dataset Access (No Cloud Storage)
 ```json
-{"role":"file_access", "permission": "READ", "table": "file://*"}
+{"role":"restricted", "permission": "READ", "table": "opteryx.*"}
 ```
-Grants read access to all local file system paths using the `file://` protocol.
+Users with the `restricted` role can only access tables in the `opteryx.*` namespace, but cannot access `file://`, `gs://`, or `s3://` paths.
 
-### Google Cloud Storage Access
+#### Grant a Role Access to Dataset and GCS
 ```json
-{"role":"gcs_access", "permission": "READ", "table": "gs://*"}
+{"role":"data_analyst", "permission": "READ", "table": "opteryx.*"}
+{"role":"data_analyst", "permission": "READ", "table": "gs://*"}
 ```
-Grants read access to all Google Cloud Storage paths using the `gs://` protocol.
+Users with the `data_analyst` role can access both `opteryx.*` tables and any `gs://` paths.
 
-### Amazon S3 Access
+#### Grant a Role Access to All Cloud Protocols
 ```json
-{"role":"s3_access", "permission": "READ", "table": "s3://*"}
+{"role":"data_engineer", "permission": "READ", "table": "opteryx.*"}
+{"role":"data_engineer", "permission": "READ", "table": "file://*"}
+{"role":"data_engineer", "permission": "READ", "table": "gs://*"}
+{"role":"data_engineer", "permission": "READ", "table": "s3://*"}
 ```
-Grants read access to all Amazon S3 paths using the `s3://` protocol.
-
-## Examples
-
-### Restrict Access to Specific Protocols
+Users with the `data_engineer` role can access all data sources.
 
-A user with only the `restricted` role can only access tables in the `opteryx.*` namespace:
+#### Grant a Role Access to Specific GCS Buckets
 ```json
-{"role":"restricted", "permission": "READ", "table": "opteryx.*"}
+{"role":"project_team", "permission": "READ", "table": "gs://project-bucket/*"}
 ```
+Users with the `project_team` role can only access paths in the `gs://project-bucket/` bucket.
 
-### Grant Multi-Protocol Access
-
-A user can have multiple roles to access different protocols:
-- Role `file_access` + role `gcs_access` → can access both `file://` and `gs://` paths
-- Role `restricted` + role `s3_access` → can access `opteryx.*` tables and `s3://` paths
+## Default Access
 
-### Default Access
-
-The system includes a default role `opteryx` that has access to everything:
+The system includes a default role `opteryx` with wildcard access to everything:
 ```json
 {"role":"opteryx", "permission": "READ", "table": "*"}
 ```
+This is added automatically and cannot be overridden by the permissions.json file.
 
 ## Usage in Queries
 
-When you query using protocol prefixes, the permission system checks the full table name:
+When you query using protocol prefixes, the permission system checks if your role has access to that table pattern:
 
 ```sql
--- Requires 'gcs_access' role or 'opteryx' role
+-- Requires a role with permission for "gs://*" pattern
 SELECT * FROM gs://my-bucket/data/*.parquet
 
--- Requires 's3_access' role or 'opteryx' role
+-- Requires a role with permission for "s3://*" pattern
 SELECT * FROM s3://my-bucket/logs/2024-01-??.csv
 
--- Requires 'file_access' role or 'opteryx' role
+-- Requires a role with permission for "file://*" pattern
 SELECT * FROM file://path/to/data/*.csv
 
--- Requires 'restricted' role or 'opteryx' role
+-- Requires a role with permission for "opteryx.*" pattern
+SELECT * FROM opteryx.space_missions
+```
+
+## Multiple Roles
+
+Users can have multiple roles. If any role grants access to a table pattern, the user can access it:
+
+```sql
+-- User with roles ["restricted", "cloud_user"] where:
+-- - "restricted" has permission for "opteryx.*"
+-- - "cloud_user" has permission for "gs://*"
+
+-- ✓ Allowed - restricted role grants access
 SELECT * FROM opteryx.space_missions
+
+-- ✓ Allowed - cloud_user role grants access  
+SELECT * FROM gs://bucket/data/*.parquet
+
+-- ✗ Denied - no role grants access
+SELECT * FROM s3://bucket/data/*.parquet
 ```
 
 ## Security Best Practices
 
 1. **Least Privilege**: Only grant the minimum permissions needed for each role
-2. **Separate Roles**: Create separate roles for different data sources (file, GCS, S3, databases)
-3. **Monitor Access**: Log and review which roles access which data sources
-4. **Audit Regularly**: Review and update permissions as access requirements change
+2. **Namespace Separation**: Use table patterns to restrict access to specific namespaces or buckets
+3. **Protocol Control**: Explicitly grant or deny protocol access (file://, gs://, s3://) per role
+4. **Monitor Access**: Log and review which roles access which data sources
+5. **Audit Regularly**: Review and update permissions as access requirements change
 
 ## Testing
 

testdata/permissions.json

@@ -1,4 +1 @@
 {"role":"restricted", "permission": "READ", "table": "opteryx.*"}
-{"role":"file_access", "permission": "READ", "table": "file://*"}
-{"role":"gcs_access", "permission": "READ", "table": "gs://*"}
-{"role":"s3_access", "permission": "READ", "table": "s3://*"}