Avi Kivity 73428c96bd Merge "Refined security model for roles" from Jesse
"This patch series refines the security model for the upcoming switch to
roles-based access control. Roles are still do not have any function,
but CQL statements related to roles manipulate metdata. The next major
patch series after this one will switch the system to roles.

Previously, most operations around roles required superuser, but this
violates an important idea in security called the "principal of least
privilege": that a user should have only the minimum access possible to
resources in order to achieve their objective.

To that end, this patch series introduces permissions on role resources.
For example, to grant a role to a user, the performing user must have
been granted AUTHORIZE on the role being granted.

In the table below, a user (role) that has been granted the permission
in the left-most column can perform the CQL query in the right columns
depending on if the permission has been granted to the root role
resource (all roles), or a particular role resource.

Perm.           All roles               Specific role (r)
---------------------------------------------------------
CREATE          CREATE ROLE

ALTER           ALTER ROLE *            ALTER ROLE r

DROP            DROP ROLE *             DROP ROLE r

AUTHORIZE       GRANT ROLE */REVOKE     GRANT ROLE r/
                ROLE *                  REVOKE ROLE r

DESCRIBE        LIST ROLES

The following restrictions around superuser exist:

- CREATE ROLE: Only a superuser can create a superuser role.

- ALTER ROLE: Only a superuser can alter the superuser status of a role.

- ALTER ROLE: You cannot alter the superuser status of yourself or of a
  role granted to you.

- DROP ROLE: Only a superuser can drop a role that has superuser.

The following additional "escape hatches" apply:

- ALTER ROLE: You can alter yourself (except to give yourself
  superuser).

- LIST ROLES: You can list your own roles and list the roles of any role
  granted to you.

Finally, a note on terminology: I like to say a role (or user) "is"
superuser if the role (user) has directly been marked as a superuser. A
role (user) "has" superuser if they have been granted a role that is a
superuser. The second statement encompasses the first, since a role can
always be said to have been granted to itself.

Fixes #2988."

* 'jhk/role_permissions/v2' of https://github.com/hakuch/scylla: (24 commits)
  auth: Move permissions cache instance to service
  auth: Add roles query function to service
  cql3: Update access checks for `revoke_role_statement`
  cql3: Update access checks in `grant_role_statement`
  cql3: Update access checks in `list_roles_statement`
  cql3: Update access checks in `drop_role_statement`
  cql3: Update access checks in `alter_role_statement`
  cql3: Update access checks in `create_role_statement`
  tests: Switch to dedicated testing superuser
  auth: Publicize enforcing check for service
  tests: Expose client state from test env
  Allow checking permissions from `client_state`
  auth: Support querying for granted superuser
  auth/service.hh: Document the class
  cql3: Change `create_role_statement` base
  cql3/Cql.g: Add role resources to grammar
  cql3/Cql.g: Avoid extra copy of `auth::resource`
  auth:resource.cc: Use `string_view` in reverse map
  auth: Add `role` resource kind
  auth: Add the DESCRIBE permission
  ...
2017-12-12 19:52:10 +02:00
2017-12-04 12:33:24 +02:00
2017-12-12 11:00:38 +02:00
2017-11-21 13:24:07 +02:00
2017-06-23 11:35:35 -04:00
2017-02-02 10:35:14 +00:00
2017-11-15 23:22:42 -05:00
2017-11-15 23:22:42 -05:00
2017-08-27 13:11:33 +03:00
2017-10-02 16:49:24 +02:00
2016-09-28 17:34:16 +03:00
2017-06-23 11:35:35 -04:00

Scylla

Quick-start

$ git submodule update --init --recursive
$ sudo ./install-dependencies.sh
$ ./configure.py --mode=release
$ ninja-build -j4 # Assuming 4 system threads.
$ ./build/release/scylla
$ # Rejoice!

Please see HACKING.md for detailed information on building and developing Scylla.

Running Scylla

  • Run Scylla
./build/release/scylla

  • run Scylla with one CPU and ./tmp as data directory
./build/release/scylla --datadir tmp --commitlog-directory tmp --smp 1
  • For more run options:
./build/release/scylla --help

Building Fedora RPM

As a pre-requisite, you need to install Mock on your machine:

# Install mock:
sudo yum install mock

# Add user to the "mock" group:
usermod -a -G mock $USER && newgrp mock

Then, to build an RPM, run:

./dist/redhat/build_rpm.sh

The built RPM is stored in /var/lib/mock/<configuration>/result directory. For example, on Fedora 21 mock reports the following:

INFO: Done(scylla-server-0.00-1.fc21.src.rpm) Config(default) 20 minutes 7 seconds
INFO: Results and/or logs in: /var/lib/mock/fedora-21-x86_64/result

Building Fedora-based Docker image

Build a Docker image with:

cd dist/docker
docker build -t <image-name> .

Run the image with:

docker run -p $(hostname -i):9042:9042 -i -t <image name>

Contributing to Scylla

Guidelines for contributing

Description
No description provided
Readme 439 MiB
Languages
C++ 72.3%
Python 26.5%
CMake 0.3%
GAP 0.3%
Shell 0.3%