Advisories for Golang/Github.com/Authzed/Spicedb package

If a schema includes the following characteristics: Permission defined in terms of a union (+) That union references the same relation on both sides, but one side arrows to a different permission Then you might have missing LookupResources results when checking the permission. This only affects LookupResources; other APIs calculate permissionship correctly. A small concrete example: relation doer_of_things: user | group#member permission do_the_thing = doer_of_things + doer_of_things->admin A CheckPermission on …

Users who: Use the exclusion operator somewhere in their authorization schema. Have configured their SpiceDB server such that –write-relationships-max-updates-per-call is bigger than 6500. Issue calls to WriteRelationships with a large enough number of updates that cause the payload to be bigger than what their datastore allows. Users will: Receive a successful response from their WriteRelationships call, when in reality that call failed. Receive incorrect permission check results, if those relationships …

On schemas involving arrows with caveats on the arrow’ed relation, when the path to resolve a CheckPermission request involves the evaluation of multiple caveated branches, requests may return a negative response when a positive response is expected. For example, given this schema: definition user {} definition office { relation parent: office relation manager: user permission read = manager + parent->read } definition group { relation parent: office permission read = …

Clients that have enabled LookupResources2 and have caveats in the evaluation path for their requests can return a permissionship of CONDITIONAL with context marked as missing, even then the context was supplied. LookupResources2 is the new default in SpiceDB 1.37.0 and has been opt-in since SpiceDB 1.35.0

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

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

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

Any user making a negative authorization decision based on the results of a LookupSubjects request with version before v1.30.1 is affected.

Any SpiceDB cluster with any schema where a resource being checked has more than 65535 relationships for the same resource and subject type is affected by this problem. The issue may also lead to a panic rendering the server unavailable The following API methods are affected: CheckPermission BulkCheckPermission LookupSubjects Impact Permission checks that are expected to be allowed are instead denied, and lookup subjects will return fewer subjects than expected. …

SpiceDB is an open source, Google Zanzibar-inspired database for creating and managing security-critical application permissions. Prior to version 1.27.0, when the provided datastore URI is malformed (e.g. by having a password which contains :) the full URI (including the provided password) is printed, so that the password is shown in the logs. Version 1.27.0 patches this issue.

SpiceDB is an open source, Google Zanzibar-inspired, database system for creating and managing security-critical application permissions. Any user making a negative authorization decision based on the results of a LookupResources request with 1.22.0 is affected. For example, using LookupResources to find a list of resources to allow access to be okay: some subjects that should have access to a resource may not. But if using LookupResources to find a list …

Background The spicedb serve command contains a flag named –grpc-preshared-key which is used to protect the gRPC API from being accessed by unauthorized requests. The values of this flag are to be considered sensitive, secret data. The /debug/pprof/cmdline endpoint served by the metrics service (defaulting running on port 9090) reveals the command-line flags provided for debugging purposes. If a password is set via the –grpc-preshared-key then the key is revealed …

SpiceDB is a database system for managing security-critical application permissions. Any user making use of a wildcard relationship under the right hand branch of an exclusion or within an intersection operation will see Lookup/LookupResources return a resource as "accessible" if it is not accessible by virtue of the inclusion of the wildcard in the intersection or the right side of the exclusion. In v1.3.0, the wildcard is ignored entirely in …