The KVS system currently lacks API endpoints to manage ResourceMetadata for key-value paths (/kv/{path}). While the AuthService and permissions.go implement robust permission checking based on OwnerUUID, GroupUUID, and Permissions, there are no exposed routes to:
Assign group-level permissions: Users cannot grant read/write access to specific groups for a given key-value path.
Change resource ownership: Users cannot transfer ownership of a key-value entry to another user.
This prevents administrators from fully leveraging the existing authentication and authorization framework for fine-grained access control over stored data.
Impact:
Limited administrative control over data access.
Inability to implement granular, group-based access policies for KV data.
Difficulty in reassigning data ownership when users or roles change.
Proposed Solution:
Implement new API endpoints (e.g., /kv/{path}/metadata) to allow authenticated and authorized users to:
Set/update the OwnerUUID for a given path.
Set/update the GroupUUID for a given path.
Set/update the Permissions bitmask for a given path.
Relevant Files:
server/routes.go (for new API routes)
server/handlers.go (for implementing new handlers)
auth/auth.go (for AuthService methods to interact with ResourceMetadata)
auth/permissions.go (existing logic for permission checks)
types/types.go (for ResourceMetadata structure)
The KVS system currently lacks API endpoints to manage ResourceMetadata for key-value paths (/kv/{path}). While the AuthService and permissions.go implement robust permission checking based on OwnerUUID, GroupUUID, and Permissions, there are no exposed routes to:
Assign group-level permissions: Users cannot grant read/write access to specific groups for a given key-value path.
Change resource ownership: Users cannot transfer ownership of a key-value entry to another user.
This prevents administrators from fully leveraging the existing authentication and authorization framework for fine-grained access control over stored data.
Impact:
Limited administrative control over data access.
Inability to implement granular, group-based access policies for KV data.
Difficulty in reassigning data ownership when users or roles change.
Proposed Solution:
Implement new API endpoints (e.g., /kv/{path}/metadata) to allow authenticated and authorized users to:
Set/update the OwnerUUID for a given path.
Set/update the GroupUUID for a given path.
Set/update the Permissions bitmask for a given path.
Relevant Files:
server/routes.go (for new API routes)
server/handlers.go (for implementing new handlers)
auth/auth.go (for AuthService methods to interact with ResourceMetadata)
auth/permissions.go (existing logic for permission checks)
types/types.go (for ResourceMetadata structure)
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The KVS system currently lacks API endpoints to manage ResourceMetadata for key-value paths (/kv/{path}). While the AuthService and permissions.go implement robust permission checking based on OwnerUUID, GroupUUID, and Permissions, there are no exposed routes to:
This prevents administrators from fully leveraging the existing authentication and authorization framework for fine-grained access control over stored data.
Impact:
Proposed Solution:
Implement new API endpoints (e.g., /kv/{path}/metadata) to allow authenticated and authorized users to:
Relevant Files:
works!