You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
MB-71275 - better permissions handling in the document editor
This issue came out of CBSE-22470, where a customer noted problems
with a user who lacked `collections!read` permission on some buckets,
but had the permission for other buckets. The bucket/scope/collection
menu in the documents page would allow the user to select both
permitted and non-permitted buckets, but no scopes/collections were
shown for the non-permitted buckets.
The user in question had permissions for Query System Catalog, but the
UI was trying to use the non-permitted `/pools/default` endpoint to
retrieve the list of scopes and collections for the bucket.
The UI would default to the `pools/default` endpoint if the user had
'cluster.collection[.:.:.].collections!read' permissions, which means
the right to list scopes/collections for at least one bucket. But that
doesn't mean that they have the right to list scopes/collections for
*every* bucket.
The code has been unchanged for the past 4 years, and this is the
first time a customer has run into the problem. However, it looks like
the use of permissions in the document editor was never really correct
after the addition of collections in release 7.0.
Problem 1: there are two separate APIs to list scopes/collections,
which require *different* permissions. The `/pools/default/buckets`
endpoint requires 'cluster.collection[bucket:.:.].collections!read'
permission. However, the same information can be retrieved from the
query service if the user has the 'Query System Catalog' role. A user
might have one of those permissions but not both, thus the code must
check and use the appropriate endpoint.
Problem 2: there are two separate APIs for retrieving documents. A
user with only 'data.docs!read' permission can't use the query
endpoint, but a user with 'n1ql.select!execute' can use either the
query endpoint or '/pools/default/buckets'. And of course these
permissions are independent of those described in Problem 1.
Problem 3: to determine whether to permit document editing, the UI was
only checking bucket-level permissions, and not collection-level
permissions. Thus it might allow the user to try and edit a document
in a read-only collection if there was some other collection in the
bucket that is writeable. The back-end would prevent the edit, but
that doesn't look good.
Solution 1: Retrieve the 'collections!read' permission for every
bucket when the document editor is initialized. The code was already
retrieving whether the user has Query Sytem Catalog, so now the code
can determine if the user has permission to fetch scope/collections,
and if so which of the two APIs to use.
Solution 2: Whenever a collection is selected in the document editor,
if needed fetch the permissions for that specific collection
w.r.t. 'docs!read', 'docs!upsert', 'docs!delete', and
'n1ql.select!execute'. With this information the code knows which APIs
are available for fetching documents, and whether the documents are
read-only, read-write, or write-only. (Yes, it is actually possible to
create documents in a collection where the user doesn't have read
access!)
Change-Id: Ie495af092f4330b7388060b265251e4a14f58db2
Reviewed-on: https://review.couchbase.org/c/query-ui/+/242881
Reviewed-by: Piotr Najda <piotr.najda@couchbase.com>
Tested-by: Eben Haber <eben@couchbase.com>
Well-Formed: Restriction Checker
meta.errors.push(`No permission to read scopes and collections for ${bucket}. User needs either 'cluster.collection[${bucket}:.:.].collections!read' or 'cluster.n1ql.meta!read'`);
0 commit comments