sql-server
), it relies upon the grant tables (mysql.user
, mysql.db
, etc.) to control user access. Access is determined by the privileges that a user has. For more information on the basics of how users and privileges work and how to use them, please read our blog post from when we announced their inclusion into Dolt. This document will assume some familiarity with users and privileges.sql-server
mode. All other commands, including all permutations of sql
, operate with privilege access checks disabled. Currently, the only way to remotely interact with a dolt database is when a database is running under server mode, therefore it is the only context where it is sensible for users to exist. As all other commands require file-level access to a database's files, any possible protection offered by other commands enabling users could easily be circumvented by directly modifying the data within the database files.sql-server
mode, you may pass in the --privilege-file="PATH"
argument. "PATH"
represents the path to the privileges file, generally named privs.json
.sql-server
mode, you may add the privilege_file: PATH
line to your YAML config. PATH
represents the path to the privileges file, generally named privs.json
.--user
and --password
arguments (see the docs for their defaults, also available using YAML configuration), whereby a server would only allow connections that supplied that singular user and password combination. Although Dolt now supports users in a similar fashion to MySQL, we still retain the user and password arguments. In MySQL, the default super account (generally called the root user) is created during installation and configuration. Rather than creating a parallel with init
, we handle the super account creation when starting a server via the arguments. Rather than creating this super account during init
, we instead handle the super account creation when starting a server via the arguments.CREATE USER
, GRANT
, REVOKE
, etc.) executes, the users and all privileges will save to the privilege file. This includes the super account as defined by the user and password arguments, therefore it is recommended that the super account is deleted after all users are set up, or it is given a strong password. On subsequent server starts, if the privilege file contains any data, the user and password arguments are fully ignored. This behavior was chosen so that server should always have at least one user that a client may log into, otherwise the server would be completely inaccessible.sql-server
mode. You may also directly edit the privilege file, which is detailed below. Dolt comes with a MySQL client built-in, which is the sql-client
command. In addition to allowing access to a running server, the client command also has the --dual
flag which runs a server in the background, while the foreground automatically connects to the background server using the given port, etc.--user
and --password
arguments (also available via a YAML configuration file) only function as login credentials. Otherwise, the arguments handle both the creation of a super account and login credentials.root
localhost
test_role
SELECT
, INSERT
, UPDATE
, and DELETE
on all databases and tablestest_user
DROP
privilege on the table some_tbl
in the database some_db
CREATE
and DROP
privileges on the other_db
databasetest_role
has been granted to test_user
"Columns"
field is present, but is currently unusedCREATE USER
, GRANT
, REVOKE
, etc.). Directly modifying the grant tables using INSERT
, UPDATE
, etc. will cause an immediate update to all current users, however it will not be immediately persisted to the privilege file. The privilege file is only updated when the aforementioned statements are executed. This may change in the future.CREATE ROLE
DROP ROLE
DROP USER
SHOW PRIVILEGES
mysql.user
mysql.db
mysql.tables_priv
mysql.role_edges
CREATE USER
mysql_native_password
for authenticationDEFAULT ROLE
and multiple auth options, are either ignored or will throw an errorGRANT
GRANT <privileges> ON <privilege_level> TO <users...>
does not yet support columns, an object type (tables only), or assuming a different userGRANT <roles...> TO <users...> [WITH ADMIN OPTION]
is fully supportedGRANT PROXY ...
is not yet supportedREVOKE
REVOKE <privileges...> ON <privilege_level> FROM <users...>
does not yet support columns or an object type (tables only)REVOKE <roles...> FROM <users...>
is fully supportedREVOKE PROXY ...
is not yet supportedREVOKE ALL PRIVILEGES ...
is not yet supported, which differs from REVOKE ALL ON ...
in functionalitySHOW GRANTS
[USING <roles...>]
portion is not yet supportedALTER USER
RENAME USER
SET DEFAULT ROLE
SET PASSWORD
SET ROLE
mysql.global_grants
mysql.columns_priv
mysql.procs_priv
mysql.proxies_priv
mysql.default_roles
mysql.password_history
mandatory_roles
activate_all_roles_on_login
SET ROLE
is also not yet implemented, any granted roles are automatically active when granted and logging inSET ROLE
is implementedDOLT_COMMIT()
, DOLT_CHECKOUT()
, etc.) as well as only allowing specific users to manage specific branches, just to name a few of the planned features. This page will be updated as features are added!