GRANT PRIVILEGES

[NEW in v4.0] - Server, Database/Project privileges.
[NEW in v13.0] - Table privileges.

This command allows you to assign privileges to a Valentina Server user.

grant_privilege_statement
    :    GRANT privileges TO grantee_list 

privileges
    :    object_privileges ON [object_type] object_name


object_name
    :    DATABASE db_name 	  	[.*]
    |    PROJECT  vext_project_name 	[.*]
    |    TABLE    table_name


object_privileges
    :    ALL [PRIVILEGES] 
    |    action [, ...]

action
    : NONE     // VDB, NON-standard
    | READ     // VDB, NON-standard

    | DELETE   // STD
    | INSERT   // STD
    | UPDATE   // STD

grantee_list
    :    character_string_literal [, ...]

object_type

The type of object for which privileges are granted.

object_name

The name of the object for which privileges are granted.
In the case of table privileges - a fully qualified name is required (“db1.t1” instead of “t1”).

privileges

It could be ALL or one of the following:

• NONE - No privileges.
• READ - Read privilege (can be used for DB only).

• INSERT - Insert privilege.
• UPDATE - Update privilege.
• DELETE - Delete privilege.

grantee_list

the list of users who are grantees of privileges for object_name.

This command forces Valentina Server to grant privileges for particular objects to users mentioned in the grantee list. This command is available for ADMINISTRATORs of vserver only.

• Please note, it is hierarchy-like permissions. Assume the database has “insert” permission, so “insert” is allowed for any table for the user. But if a particular table has its own set of permissions - the parent's db rules are ignored.
• Also note - changing permissions for the user does not affect active sessions.

• You have to always provide at least READ privilege to the DB. Otherwise, the DB would not be even able to open for the user.


If the vserver variable PrivilegesEnable is set to zero (see vServer INI file for details) no privileges checks are performed at all. It means all users are granted for any db operation (granted privileges are still stored but play no role in this mode).

• ERR_CONNECTION_OPERATION_NOT_PERMITTED - Valentina is running in local mode or the query-issuer is not an administrator of Valentina Server.

• ERR_CONNECTION_USER_NOT_EXISTS - some user mentioned in grantee_list is not exist.

• ERR_DB_NOT_FOUND - database with the specified name is not registered to Valentina Server.

• ERR_DB_IDENTIFIER_NOT_FOUND - The database does not contain the object with the specified name.

Example:

User1 should have all privileges to work with db1:

GRANT ALL ON DATABASE db1.* TO 'User1';

Example:

User1 should be able to insert new data into the database (but he is not able to delete, update data or alter database schema):

GRANT INSERT ON DATABASE db1.* TO 'User1';

Example:

User1 should be able to insert and delete data (but he is not able to update data or alter database schema):

GRANT INSERT, DELETE ON DATABASE db1.* TO 'User1';

Example:

Suppose you want to provide full access for all the tables except t1, which must be available for insert/delete only:

GRANT ALL ON db1.* TO 'User1';

GRANT INSERT, DELETE ON TABLE "db1.t1" TO 'User1';