sql-server), it relies upon the grant tables (
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-servermode. 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.
--passwordarguments (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.
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-servermode. You may also directly edit the privilege file, which is detailed below. Dolt comes with a MySQL client built-in, which is the
sql-clientcommand. In addition to allowing access to a running server, the client command also has the
--dualflag which runs a server in the background, while the foreground automatically connects to the background server using the given port, etc.
--passwordarguments (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.
DELETEon all databases and tables
DROPprivilege on the table
some_tblin the database
DROPprivileges on the
test_rolehas been granted to
"Columns"field is present, but is currently unused
REVOKE, etc.). Directly modifying the grant tables using
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.
DEFAULT ROLEand multiple auth options, are either ignored or will throw an error
GRANT <privileges> ON <privilege_level> TO <users...>does not yet support columns, an object type (tables only), or assuming a different user
GRANT <roles...> TO <users...> [WITH ADMIN OPTION]is fully supported
GRANT PROXY ...is not yet supported
REVOKE <privileges...> ON <privilege_level> FROM <users...>does not yet support columns or an object type (tables only)
REVOKE <roles...> FROM <users...>is fully supported
REVOKE PROXY ...is not yet supported
REVOKE ALL PRIVILEGES ...is not yet supported, which differs from
REVOKE ALL ON ...in functionality
[USING <roles...>]portion is not yet supported
SET DEFAULT ROLE
SET ROLEis also not yet implemented, any granted roles are automatically active when granted and logging in
SET ROLEis implemented
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!