-
Notifications
You must be signed in to change notification settings - Fork 94
Buckets and Users
This page tries to describe how buckets and users are represented and stored, in Riak CS.
- Data structure, aka schema-ish
- How they are updated, read and managed consistent
- Bucket metadata
- User metadata
- ACLs and Policies
Users are represented as a record in
the big one header. It
is t2b'd and stored in moss.users
bucket with a key represented by
access key. It contains user name, display name, access key, secret
key, canonical ID, the list of all buckets.
Note that there are several indexes on this, with Email, Canonical ID to guarantee uniqueness when creating a user.
Sibling resolution of user record is implemented in
riak_cs_user:from_riakc_obj/2
(not exported).
Buckets are represented as
a record
in user record. It also has another entry in moss.buckets
bucket with a
key represented by bucket name. Note that
bucket ACLs
and
bucket policies
are stored in metadata of this entry, with metadata key X-Moss-Acl
and X-Rcs-Plicy
respectively.
Bucket name must be unique, RFC1355 compliant.
Summary: all update requests are through Stanchion. But user update is a little bit trickey - only bucket update is serialized by Stanchion.
Critical sections of all APIs on updating users and buckets are via
velvet
(merged in main CS repo since 2.1).
- CS makes sure no bucket record entry with same name exists in
moss.buckets
of Riak - CS performs
PUT
to Stanchion, with the name of the creator - Stanchion makes sure no manifests remains in the manifest bucket, and no bucket record entry with the same name exists
- Stanchion performs put bucket object to
moss.buckets
- CS performs update on user record (at
moss.users
)
Updates and deletes have mostly the same flow.
- CS generates a new user's key and secret from UUID v4 binary
- CS checks a new user's email is not already used via 2i query
- Stanchion makes that the email of the user is available
- Stanchion puts a user record to
moss.users
For development purpose, riak_cs_user:create_user/4
via attached
console is the fastest way to create a new user.
- CS checks the user exists
- Stanchion makes sure that the new email address is available if changed
- Stanchion puts a user record to
moss.users
Bucket object (r_o
) is updated via
Stanchion. riak_cs_wm_utils:bucket_access_authorize_helper/4
,
riak_cs_wm_utils:object_access_authorize_helper/4
and
riak_cs_wm_utils:object_access_authorize_helper/5
would be a good
introduction to learn application of ACL and Policy.
Access Control Lists is tested first and Bucket Policies (example) are tested next. After them quota modules are evaluated. See quota code document.