SpiceDB: Checks involving relations with caveats can result in unconditional permission when conditional permission is expected
Under concurrency, CheckPermission and CheckBulkPermissions can return PERMISSIONSHIP_HAS_PERMISSION for a (resource, permission, subject) whose correct answer is PERMISSIONSHIP_CONDITIONAL_PERMISSION.
You are impacted if all of the following hold:
definition user {}
caveat some_caveat(somecondition int) { somecondition == 42 }
definition document {
relation reader: user | user with some_caveat
relation writer: user
relation banned: user
permission has_permission = (reader & writer) - banned
}
document:firstdoc#reader@user:caveatedreader[some_caveat]
document:firstdoc#writer@user:caveatedreader
LookupResources with a context request parameter, concurrently with CheckPermission/CheckBulkPermissions for the same subject/resource, andWhen all of the above are true, there is an intermittent window in which:
CheckPermission(document:firstdoc, has_permission, user:caveatedreader) → HAS_PERMISSION (incorrect; should be CONDITIONAL_PERMISSION)
CheckPermission(document:firstdoc, has_permission, user:caveatedreader, context = {"somecondition": 41}) → HAS_PERMISSION (incorrect; should be NO_PERMISSION)
v1.54.0
Disable the dispatch result cache (ClusterDispatchCacheConfig and DispatchCacheConfig)
왜 이 VPI인가 (설명가능 · 실험적)
VPI 산정 기준
| 영향도 | 37.00 |
| 악용 신호(추가 악용신호 없음) | ×1.00 |
| VPI | 37.00 |
VPI 공식 vpi-v1 기준