An open API service providing security vulnerability metadata for many open source software ecosystems.

GSA_kwCzR0hTQS1qaGc2LTZxcngtMzhtcs4AA_rH

Moderate CVSS: 6.3 EPSS: 0.00085% (0.25592 Percentile) EPSS:

SpiceDB having multiple caveats on resources of the same type may improperly result in no permission

Affected Packages Affected Versions Fixed Versions
go:github.com/authzed/spicedb < 1.35.3 1.35.3
16 Dependent packages
17 Dependent repositories

Affected Version Ranges

All affected versions

0.0.1, 0.0.2, 0.0.3, 1.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0, 1.5.0, 1.6.0, 1.7.0, 1.7.1, 1.8.0, 1.9.0, 1.10.0, 1.11.0, 1.12.0, 1.13.0, 1.14.0, 1.14.1, 1.15.0, 1.16.0, 1.16.1, 1.16.2, 1.17.0, 1.18.0, 1.18.1, 1.19.0, 1.19.1, 1.20.0, 1.21.0, 1.22.0, 1.22.1, 1.22.2, 1.23.0, 1.23.1, 1.24.0, 1.25.0, 1.26.0, 1.27.0, 1.28.0, 1.29.0, 1.29.1, 1.29.2, 1.29.4, 1.29.5, 1.30.0, 1.30.1, 1.31.0, 1.32.0, 1.33.0, 1.33.1, 1.34.0, 1.35.0, 1.35.1, 1.35.2

All unaffected versions

1.35.3, 1.36.0, 1.36.1, 1.36.2, 1.36.3, 1.37.0, 1.37.1, 1.37.2, 1.38.0, 1.38.1, 1.39.0, 1.39.1, 1.40.0, 1.40.1, 1.41.0, 1.42.0, 1.42.1, 1.43.0, 1.44.0, 1.44.2, 1.44.3, 1.44.4, 1.45.0, 1.45.1

Background

Multiple caveats over the same indirect subject type on the same relation can result in no permission being returned when permission is expected

For example, given this schema:

definition user {}

caveat somecaveat(somefield int) {
  somefield == 42
}

definition group {
  relation member: user
}

definition resource {
  relation viewer: group#member with somecaveat
  permission view = folder->view
}

If the resource has multiple groups, and each group is caveated, it is possible for the returned permission to be "no permission" when permission is expected.

Impact

Permission is returned as NO_PERMISSION when PERMISSION is expected on the CheckPermission API.

Workarounds

Do not use caveats or do not use caveats on an indirect subject type with multiple entries

References: