112 lines
5.1 KiB
Markdown
112 lines
5.1 KiB
Markdown
# Policy System Fix Conversation
|
|
|
|
## Initial Context
|
|
This session continued from a previous conversation about implementing policy manager requirements from GitHub Issue #5.
|
|
|
|
## User Request 1: Clarification on Privileged Flag
|
|
User: "ok, so the privileged flag relates only to read, not write"
|
|
|
|
Response: Confirmed understanding that privileged flag only affects read operations, not write operations. The privileged flag allows parties involved in an event (author or p-tagged users) to read it, but doesn't restrict who can write such events.
|
|
|
|
## User Request 2: OR Logic for Read Access
|
|
User: "read_allow and privileged both allow read access, they are not exclusive"
|
|
|
|
Response: Understood that read access should use OR logic - a user can read if they are in the read_allow list OR if they are involved in a privileged event. Previously the implementation was treating them as mutually exclusive.
|
|
|
|
## Implementation Changes Made
|
|
|
|
### 1. Privileged Flag - Read Only
|
|
- Removed privileged checks from write operations
|
|
- Updated all write-related tests to reflect that privileged doesn't affect write operations
|
|
- Modified policy.go to only check privileged flag for read operations
|
|
|
|
### 2. OR Logic for Read Access
|
|
- Implemented OR logic in checkRulePolicy for read operations
|
|
- Three cases handled:
|
|
a. With allow list: user in list OR (privileged AND involved) = allow
|
|
b. Without allow list but privileged: only involved parties = allow
|
|
c. Neither: continue to other checks
|
|
|
|
### 3. Test Updates
|
|
- Updated TestCheckRulePolicy to reflect privileged doesn't affect write
|
|
- Updated TestReadAllowWithPrivileged to use OR logic
|
|
- Updated TestSamplePolicyFromUser to use OR logic
|
|
- Updated TestPolicyIntegration to remove privileged write restrictions
|
|
- Updated precedence_test.go to document OR logic behavior
|
|
|
|
### 4. Bug Fixes
|
|
- Fixed empty read_allow list with privileged flag allowing everyone
|
|
- Now correctly restricts to involved parties only
|
|
|
|
## User Request 3: Implicit Kind Whitelist
|
|
User: "ok, i have just seen that the kinds in global policy fields or the set that have rules specified should be allowed, otherwise denied"
|
|
|
|
Response: Implemented implicit kind whitelist based on rule presence:
|
|
- If specific rules exist, only kinds with rules are allowed
|
|
- If only global rule exists (no specific rules), all kinds allowed
|
|
- If no rules at all, all kinds allowed (falls to default policy)
|
|
|
|
Updated checkKindsPolicy logic to:
|
|
1. Check explicit whitelist first (backwards compatibility)
|
|
2. Check explicit blacklist second (backwards compatibility)
|
|
3. Otherwise use implicit whitelist based on rule presence
|
|
|
|
## User Request 4: Security - Reject Unauthenticated
|
|
User: "make sure if there is no authed pubkey, just reject everything"
|
|
|
|
Response: Added critical security check at the beginning of CheckPolicy:
|
|
```go
|
|
// CRITICAL SECURITY: Reject all unauthenticated access
|
|
if len(loggedInPubkey) == 0 {
|
|
return false, nil // Silently reject unauthenticated users
|
|
}
|
|
```
|
|
|
|
This ensures no authentication = no access, regardless of policy rules.
|
|
|
|
## User Request 5: Create Summary
|
|
User: "summarize this chat and write to the file 'policyfixes.md' in the root of the repository"
|
|
|
|
Response: Created comprehensive policyfixes.md documenting:
|
|
- All critical conceptual fixes
|
|
- Policy evaluation order
|
|
- Important behavioral rules
|
|
- Bug fixes
|
|
- Test updates
|
|
- Files modified
|
|
|
|
## Key Insights During Implementation
|
|
|
|
1. **Submitter vs Author**: write_allow and read_allow control who can submit/read events (the logged-in user), not who authored the event. This is relay access control, not content validation.
|
|
|
|
2. **Privileged Read Pattern**: Creates a "private message" pattern where events are readable only by involved parties, but anyone can create privileged events.
|
|
|
|
3. **OR Logic Flexibility**: Combining explicit permissions (allow lists) with implicit permissions (privileged involvement) provides flexible access patterns.
|
|
|
|
4. **Implicit Kind Whitelist**: Automatically filters kinds based on rule presence, eliminating need for explicit kind configuration when rules are defined.
|
|
|
|
5. **Security by Default**: Authentication requirement at the policy layer ensures no unauthorized access regardless of policy configuration.
|
|
|
|
## Test Results
|
|
- All 336+ policy tests passing after fixes
|
|
- Comprehensive test verifies all 5 requirements from Issue #5
|
|
- Precedence tests document exact evaluation order
|
|
|
|
## Files Modified
|
|
- pkg/policy/policy.go - Core implementation
|
|
- pkg/policy/policy_test.go - Updated tests
|
|
- pkg/policy/comprehensive_test.go - New comprehensive test
|
|
- pkg/policy/precedence_test.go - Updated precedence tests
|
|
- pkg/policy/read_access_test.go - Updated for OR logic
|
|
- pkg/policy/policy_integration_test.go - Updated for privileged behavior
|
|
- docs/POLICY_FINAL_FIX_SUMMARY.md - Documentation
|
|
- policyfixes.md - Summary document (created)
|
|
|
|
## Current Status
|
|
All policy system requirements implemented and tested. The system now provides:
|
|
- Secure by default (authentication required)
|
|
- Predictable behavior (clear evaluation order)
|
|
- Flexible access control (OR logic for reads)
|
|
- Automatic kind filtering (implicit whitelist)
|
|
- Fully tested and documented
|