User Access Control

As of version 1.30.21/2.00.9, user-management functions can be executed on data nodes, while in previous versions these functions can only be called on controllers.

For the privilege rules discussed below, a user is viewed as belonging to a special group with himself/herself as the only member. The user's access privileges are determined by the privileges of the groups that he/she belongs to.

Different groups may set different access privileges to a user. For these situations the following rules apply:

• If a user is granted a privilege in one group and this privilege is not denied in any other group, then the user is granted the privilege.
• If a user is denied a privilege in at least one group, then the user's privilege is denied.

Example 1. If a user belongs to one group, and the user's permission state is deny, while the group's state is allow, then the user's permission is denied.

login("admin","123456")
createUser("user1","123456")
createGroup("group1",["user1"])
deny(`user1, DB_OWNER) // deny DB_OWNER to user1
grant(`group1, DB_OWNER) // grant DB_OWNER to group1
login("user1","123456")
database("dfs://test",VALUE,1..10) // user1 is denied
// Error: <NoPrivilege>Not granted to create or delete databases

Example 2. If a user belongs to one group, and the user's permission state is none, while the group's state is allow, then the user's permission is granted.

login("admin","123456")
revoke(`user1, DB_OWNER) // revoke the denied DB_OWNER
grant(`group1, DB_OWNER) // grant DB_OWNER to group1
login("user1","123456")
database("dfs://test",VALUE,1..10) // user1 is granted

Example 3. If a user belongs to one group, and the user's permission state is none, while the group's state is deny, then the user's permission is denied.

login("admin","123456")
revoke(`user1, DB_OWNER) // revoke the denied DB_OWNER
deny(`group1, DB_OWNER) // deny DB_OWNER to group1
login("user1","123456")
database("dfs://test",VALUE,1..10)//  user1 is denied
// Error: <NoPrivilege>Not granted to create or delete databases

Example 4. If a user belongs to multiple groups, and some groups' permission state is deny, while some is allow, then the user's permission is denied.

login("admin","123456")
createGroup("group2",["user1"])
createGroup("group3",["user1"])
deny(`group1, DB_OWNER)
grant(`group2, DB_OWNER)
grant(`group3, DB_OWNER)
login("user1","123456")
database("dfs://test",VALUE,1..10) // user1 is denied
// Error: <NoPrivilege>Not granted to create or delete databases

Example 5. If a user belongs to multiple groups, and some groups' permission state is none, while some is allow, then user's permission is granted.

login("admin","123456")
revoke(`group1, DB_OWNER)
grant(`group2, DB_OWNER)
grant(`group3, DB_OWNER)
login("user1","123456")
database("dfs://test",VALUE,1..10) // user1 is granted

Example 6. If a user belongs to multiple groups, and some groups' permission state is none, while some is deny, then the user's permission is denied.

login("admin","123456")
revoke(`group1, DB_OWNER)
deny(`group2, DB_OWNER)
deny(`group3, DB_OWNER)
login("user1","123456")
database("dfs://test",VALUE,1..10) // user1 is denied
// Error: <NoPrivilege>Not granted to create or delete databases

Example 7. If a user belongs to a group, the user retains only his/her own privileges after the group is deleted.

login("admin","123456")
createUser("user1","123456")
createGroup("group1",["user1"])
grant(`user1, DB_OWNER) //grant DB_OWNER to user1
deny(`group1, DB_OWNER) //deny DB_OWNER to group1
deleteGroup(`group1) //delete group1
login("user1","123456")
database("dfs://test",VALUE,1..10) //user1 is granted

login("admin","123456")
createGroup("group1",["user1"])
revoke(`user1, DB_OWNER) //revoke granted DB_OWNER
grant(`group1, DB_OWNER) //grant DB_OWNER to group1
deleteGroup(`group1) //delete group1
login("user1","123456")
database("dfs://test",VALUE,1..10) //user1 is denied

Based on the application scope, permissions are divided into three scopes: global (*), database and table.

The following are privilege rules for determining permissions on databases and tables:

• If you grant/revoke/deny at a smaller scope, and then manage permissions at a larger scope, the smaller scope permissions will be invalidated and overridden by the larger scope permissions.
• If you allow at a larger scope, and then deny at a smaller scope, the deny operation will take effect while the allow permissions still apply to the objects outside of the deny scope.
• If you allow/deny at a larger scope, and then revoke at a smaller scope, the revoke operation will be invalid while the allow permissions still apply to the original scope.
• If you deny at a larger scope, and then grant at a smaller scope:
  • For versions before 1.30.21 and 2.00.9, the grant can take effect while the deny permissions still apply to the objects outside of the grant scope.
  • Since version 1.30.21 and 2.00.9, this operation is not allowed.
• If you revoke in a large scope, and then manage permissions at a smaller scope, the smaller scope permissions will take effect.

Example 1. First deny TABLE_READ at table level to user 1, then grant TABLE_READ at global level. Now user1 has the TABLE_READ access to all tables:

login("admin", "123456")
createUser("user1","123456")
dbName = "dfs://test"
if(existsDatabase(dbName)){
        dropDatabase(dbName)
}
t = table(1..10 as id , rand(100, 10) as val)
db=database(dbName, VALUE, 1..10)
pt=  db.createPartitionedTable(t, "pt", "id")
pt.append!(t)

deny("user1", TABLE_READ, dbName+"/pt")
grant("user1", TABLE_READ, "*")

login("user1", "123456")
select * from loadTable(dbName, "pt") 
// user1 is granted TABLE_READ to "dfs://test"

Example 2. First grant TABLE_READ at table level to user2, then deny TABLE_READ at global level. Now user2 is denied to access all tables:

login("admin", "123456")
createUser("user2","123456")
dbName = "dfs://test"
if(existsDatabase(dbName)){
        dropDatabase(dbName)
}
t = table(1..10 as id , rand(100, 10) as val)
db=database(dbName, VALUE, 1..10)
pt=  db.createPartitionedTable(t, "pt", "id")
pt.append!(t)

grant("user2", TABLE_READ, dbName+"/pt")
deny("user2", TABLE_READ, "*")

login("user2", "123456")
select * from loadTable(dbName, "pt") 
// user2 is denied to access "dfs://test"

Example 3. First grant TABLE_READ at table level to user3, then revoke TABLE_READ at global level. Now the TABLE_READ permissions on all tables of user3 are revoked.

login("admin", "123456")
createUser("user3","123456")
dbName = "dfs://test"
if(existsDatabase(dbName)){
        dropDatabase(dbName)
}
t = table(1..10 as id , rand(100, 10) as val)
db=database(dbName, VALUE, 1..10)
pt=  db.createPartitionedTable(t, "pt", "id")
pt.append!(t)

grant("user3", TABLE_READ, dbName+"/pt")
revoke("user3", TABLE_READ, "*")
login("user3", "123456")
select * from loadTable(dbName, "pt") 
// user3's privilege is revoked

Example 4. First grant TABLE_READ at global level to user1, then deny TABLE_READ on the table "dfs://test/pt" to user1. Now user1 is granted TABLE_READ access to all tables except "dfs://test/pt".

login("admin", "123456")
createUser("user1","123456")
dbName = "dfs://test"
t = table(1..10 as id , rand(100, 10) as val)
if(existsDatabase(dbName)){
        dropDatabase(dbName)
}
db=database(dbName, VALUE, 1..10)
pt=  db.createPartitionedTable(t, "pt", "id")
pt.append!(t)
grant("user1", TABLE_READ, "*")
deny("user1", TABLE_READ, dbName+"/pt")

login("user1", "123456")
select * from loadTable(dbName, "pt") 
// user1's access to "dfs://test/pt" is denied

Example 5. First grant TABLE_READ to user1, then revoke user1's TABLE_READ access to "dfs://test/pt". Now user1 is still granted TABLE_READ access to all tables.

login("admin", "123456")
createUser("user1","123456")
dbName = "dfs://test"
t = table(1..10 as id , rand(100, 10) as val)
if(existsDatabase(dbName)){
        dropDatabase(dbName)
}
db=database(dbName, VALUE, 1..10)
pt=  db.createPartitionedTable(t, "pt", "id")
pt.append!(t)
grant("user1", TABLE_READ, "*")
revoke("user1", TABLE_READ, dbName+"/pt")

login("user1", "123456")
select * from loadTable(dbName, "pt") 
// user1 is granted to access "dfs://test/pt"

Example 6. First deny TABLE_READ at global level to user1, then revoke the denied TABLE_READ access to table "dfs://test/pt". Now user1 is still denied to read all tables.

login("admin", "123456")
createUser("user1","123456")
dbName = "dfs://test"
if(existsDatabase(dbName)){
        dropDatabase(dbName)
}
t = table(1..10 as id , rand(100, 10) as val)
db=database(dbName, VALUE, 1..10)
pt=  db.createPartitionedTable(t, "pt", "id")
pt.append!(t)

deny("user1", TABLE_READ, "*")
revoke("user1", TABLE_READ, dbName+"/pt")

getUserAccess("user1")

Example 7. First deny TABLE_READ at global level to user1, then grant TABLE_READ on table "dfs://test/pt" to user1.

For versions before 1.30.21/2.00.9, user1 has the TABLE_READ access to table "dfs://test/pt", but the access to other tables is denied; For versions since 1.30.21/2.00.9, the grant operation will raise an error.

login("admin", "123456")
createUser("user1","123456")
dbName = "dfs://test"
if(existsDatabase(dbName)){
        dropDatabase(dbName)
}
t = table(1..10 as id , rand(100, 10) as val)
db=database(dbName, VALUE, 1..10)
pt=  db.createPartitionedTable(t, "pt", "id")
pt1=  db.createPartitionedTable(t, "pt1", "id")
pt.append!(t)
pt1.append!(t)

deny("user1", TABLE_READ, "*")
// As of 1.30.21/2.00.9 version, the grant operation reports 'Invalid grant: grant [dfs://test/pt] and [deny *] are in conflict'
grant("user1", TABLE_READ, dbName+"/pt")
login("user1", "123456")
select * from loadTable(dbName, "pt")
// In the previous versions, user1 is granted to access "dfs://test/pt"
select * from loadTable(dbName, "pt1")
// user1 is denied to access other tables

If users created before version 1.30.21/2.00.9 were granted table-level privileges like TABLE_READ and TABLE_WRITE on some tables while denied those privileges on other tables, after a server upgrade to version 1.30.21/2.00.9 or higher, they have access to all tables except those that were explicitly denied.

For example, user1 is granted TABLE_READ access to pt1, and denied TABLE_READ access to pt2 in versions before 1.30.21/2.00.9. Then user1 is only granted to access "dfs://valuedb/pt1".

login("admin","123456")
createUser("user1","123456")
grant("user1",TABLE_READ,"dfs://valuedb/pt1")
deny("user1",TABLE_READ,"dfs://valuedb/pt2")

After the server is upgraded, user1 is granted to access to all tables of database "dfs://valuedb" except pt2. The above script is equivalent to:

grant("user1",TABLE_READ,"dfs://valuedb/*")
deny("user1",TABLE_READ,"dfs://valuedb/pt2")

(1) If users created before version 1.30.21/2.00.9 were only granted DB_MANAGE but not DB_OWNER, after a server upgrade they are not allowed to create databases.

(2) If users created before version 1.30.21/2.00.9 were granted TABLE_WRITE, after a server upgrade they are also granted TABLE_INSERT, TABLE_UPDATE, and TABLE_DELETE privileges.

(3) When using grant/deny/revoke with accessType=DB_OWNER, the objs parameter for databases must end with "*", indicating the prefix pattern of databases.

login("admin", "123456")
createUser("user1","123456")
grant("user1", DB_OWNER,"*") 
// user1 is granted DB_OWNER access to all databases
grant("user1", DB_OWNER,"dfs://test0*")
// user1 is granted DB_OWNER access to all databases with a predix of "dfs://test0"

(4) When using grant/deny/revoke with accessType=DB_MANAGE, the databases specified in objs must already be created. Otherwise an error will be reported.

login("admin", "123456")
createUser("user1","123456")
grant("user1", DB_MANAGE,"dfs://test0") 
// Error: The database [dfs://test0] does not exist
grant("user1", DB_MANAGE, ["dfs://db1","dfs://db2"]) 
// Error: The database [dfs://db1] does not exist

A table-level privilege is revoked when the involved user or table is deleted, and a database-level privilege is revoked when the involved user or database is deleted. A DB_OWNER privilege is revoked only when the user and all involved databases are deleted.

For privileges applied on shared in-memory tables or streaming engines, they will not be revoked after server restarts, or when the shared tables or streaming engines are deleted. Therefore, if new shared tables or streaming engines are created with the same names, the previously-assigned privileges still take effect.

Example 1. user1 is granted TABLE_READ on table "dfs://valuedb/pt". Delete and recreate the table, and the TABLE_READ privilege is revoked from user1.

login("admin", "123456")
dbName = "dfs://valuedb"
t = table(1..10 as id , rand(100, 10) as val)
if(existsDatabase(dbName)){
        dropDatabase(dbName)
} 
db=database(dbName, VALUE, 1..10)
pt=  db.createPartitionedTable(t, "pt", "id").append!(t)
​
createUser("user1","123456")
grant("user1", TABLE_READ,"dfs://valuedb/pt")
login("user1", "123456")
select * from loadTable("dfs://valuedb",`pt)
// user1 is granted to access "dfs://valuedb/pt"
login("admin", "123456")
dropTable(db,`pt)
pt=  db.createPartitionedTable(t, "pt", "id").append!(t)
login("user1", "123456")
select * from loadTable("dfs://valuedb",`pt)
// the TABLE_READ access of user1 is revoked

Example 2. user1 is granted DB_MANAGE on the database "dfs://valuedb". Delete and recreate the database, and the DB_MANAGE privilege is revoked from user1.

login("admin", "123456")
dbName = "dfs://valuedb"
t = table(1..10 as id , rand(100, 10) as val)
if(existsDatabase(dbName)){
        dropDatabase(dbName)
}
db=database(dbName, VALUE, 1..10)
pt=  db.createPartitionedTable(t, "pt", "id").append!(t)

createUser("user1","123456")
grant("user1", DB_MANAGE,"dfs://valuedb")
getUserAccess("user1")

Now user1 is granted the DB_MANAGE access to database "dfs://valuedb".

login("admin", "123456")
if(existsDatabase(dbName)){
  dropDatabase(dbName)
}
db=database(dbName, VALUE, 1..10)
pt=  db.createPartitionedTable(t, "pt", "id").append!(t)
getUserAccess("user1")

The DB_MANAGE privilege is revoked from user1.

Example 3. The user u1 is granted read and write privileges on the stream tables "trades", "output1" and the streaming engine "agg1":

login(`admin, `123456)
createUser(`u1, "111111");
enableTableShareAndPersistence(streamTable(1000:0, `time`sym`volume, [TIMESTAMP, SYMBOL, INT]),`trades)
share streamTable(1000:0, `time`sym`volume, [TIMESTAMP, SYMBOL, INT]) as  output1
agg1 = createTimeSeriesEngine(name="agg1", windowSize=600, step=600, metrics=<[sum(volume)]>, dummyTable=trades, outputTable=output1, timeColumn=`time, useSystemTime=false, keyColumn=`sym, garbageSize=50, useWindowStartTime=false)
grant("u1", TABLE_READ, "agg1")
grant("u1", TABLE_WRITE, "agg1")
grant("u1", TABLE_READ, "trades")
grant("u1", TABLE_WRITE, "trades")
grant("u1", TABLE_READ, "output1")
grant("u1", TABLE_WRITE, "output1")
getUserAccess(`u1)

If server restarts, or a user deletes and recreates the stream table "trades", "output1" or the streaming engine "agg1", access control is not applied to these objects, and any user can access them.

login(`admin, `123456)
enableTableShareAndPersistence(streamTable(1000:0, `time`sym`volume, [TIMESTAMP, SYMBOL, INT]),`trades)
share streamTable(1000:0, `time`sym`volume, [TIMESTAMP, SYMBOL, INT]) as  output1
agg1 = createTimeSeriesEngine(name="agg1", windowSize=600, step=600, metrics=<[sum(volume)]>, dummyTable=trades, outputTable=output1, timeColumn=`time, useSystemTime=false, keyColumn=`sym, garbageSize=50, useWindowStartTime=false)

Add access control to these objects:

addAccessControl(`trades)
addAccessControl(output1)
addAccessControl(agg1)

Now only u1 and the creator admin can access these objects:

login(`u1, "111111")
insert into agg1 values(2018.10.08T01:01:01.785,`A,10) 
insert into output1 values(2018.10.08T01:01:01.785,`A,10) 
insert into trades values(2018.10.08T01:01:01.785,`A,10) 

Other users are denied:

login(`u2, "111111")
insert into agg1 values(2018.10.08T01:01:01.785,`A,10)=> No access to table [agg1]'
insert into output1 values(2018.10.08T01:01:01.785,`A,10) => No access to table [output1]'
insert into trades values(2018.10.08T01:01:01.785,`A,10) => No access to table [trades]'

The following table introduces the privileges required by DDL/DML operations before and since version 1.30.21/2.00.9.

When calling function addColumn, dropColumns!, renameColumns, replaceColumns, setColumnComment, rename!, or renameTable, if the applied object is created by other users, the current user must be granted TABLE_READ access to the table.

For example:

user 1 creates database "dfs://test" and grants user2 DBOBJ_CREATE. Then log in as user2 to create table pt1.

login("admin", "123456")
createUser("user1","123456",,true)
createUser("user2","123456",,true)
grant(`user1, DB_OWNER,"dfs://test*")

login("user1", "123456")
dbName = "dfs://test"
if(existsDatabase(dbName)){
        dropDatabase(dbName)
}
t = table(1..10 as id , rand(100, 10) as val)
db=database(dbName, VALUE, 1..10)
grant(`user2, DBOBJ_CREATE ,"dfs://test")
login("user2", "123456")
pt1=  db.createPartitionedTable(t, "pt1",`id).append!(t)

If user1 attempts to rename a column in pt1, error of no privilege is reported:

login("user1", "123456")
rename!(pt1,`val,`val1)
// Error: <NoPrivilege> Not granted to read table dfs://test/pt1'

user1 must be granted the TABLE_READ privilege on pt1:

login("admin", "123456")
grant(`user1, TABLE_READ,"dfs://test/pt1")

Then log in as user1 to re-execute the rename operation:

login("user1", "123456")
rename!(pt1,`val,`val1)
schema(loadTable(dbName,`pt1)).colDefs
------------------------------------------
name typeString typeInt extra comment
---- ---------- ------- ----- -------
id   INT        4                    
val1 INT        4                                                 

Since version 1.30.21/2.00.9, users with VIEW_EXEC privilege only cannot get expected results when executing the above functions.

For DFS databases, you can use function grant/deny/revoke to set privilege access for users or groups. The parameter accessType of these functions can take all the privilege types.

• Global or table-level privileges: TABLE_READ, TABLE_WRITE, TABLE_INSERT, TABLE_UPDATE, TABLE_DELETE
• Global or database-level privileges: DBOBJ_CREATE, DBOBJ_DELETE, DB_READ, DB_WRITE, DB_INSERT, DB_UPDATE, DB_DELETE, DB_MANAGE, DB_OWNER

Example 1. Grant user1 TABLE_READ at global level:

grant(`user1, TABLE_READ, "*")

Example 2. Grant user1 TABLE_READ of table pt in the database "dfs://valuedb":

grant(`user1, TABLE_READ,"dfs://valuedb/pt")

Example 3. Grant user1 DBOBJ_CREATE in the database "dfs://valuedb":

grant(`user1, DBOBJ_CREATE,"dfs://valuedb")

Example 4. Grant user1 the read and write privileges in a specific database (new feature in version 1.30.21/2.00.9):

login("admin","123456")
createUser("user1","123456")
grant("user1",DB_READ,"dfs://valuedb")
grant("user1",DB_WRITE,"dfs://valuedb")

Now user1 has all access privileges to database "dfs://valuedb".

Example 5. Grant user2 the privilege to create and manage databases with prefix "dfs://db0" only.

login("admin","123456")
createUser("user2","123456")
grant("user2", DB_OWNER, "dfs://db0*")

In this case, if user2 attempts to create a database with prefix "dfs://db1", the operation will be denied.

Example 6. Grant all members of a group the read privilege on a table, and only some members with write privilege.

login("admin","123456")
createUser("user1","123456")
createUser("user2","123456")
createUser("user3","123456")
createGroup("group1",["user1","user2","user3"])
grant("group1", TABLE_READ, "dfs://valuedb/pt")
createUser("user4","123456")
addGroupMember("user4","group1")
grant("user1", TABLE_WRITE, "dfs://valuedb/pt")
grant("user4", TABLE_WRITE, "dfs://valuedb/pt")

Now user1 and user4 are granted read and write privileges on table "dfs://valuedb/pt", and user2 and user3 have only the read privilege.

Example 7. grant or deny privileges on all objects (represented by *). Grant user1 the read privilege on all DFS tables:

grant("user1",TABLE_READ,"*")  

If the grant or deny operation applies to all objects, revoke can only be used to cancel the privilege settings from all objects. If only the privilege access on a specific object is revoked, the revoke operation does not take effect:

revoke("user1",TABLE_READ,"dfs://db1/t1")

Instead, use the following command to revoke granted privileges from all objects:

revoke("user1",TABLE_READ,"*")

Similarly, after using grant or deny on a group, only revoke can be used to cancel the privilege settings. Note the revoke command can only be applied to the group. If only the access of a member is revoked, the operation does not take effect.

Example 8. Grant DB_OWNER to user1. Log in as user1 to create table "dfs://dbMT/dt" and grant user2 the read privilege on the table. Now user2 now can access the table "dfs://dbMT/dt".

createUser("user1", "123456")
createUser(`user2, "123456")
grant("user1",DB_OWNER);
login("user1", "123456")
db = database("dfs://dbMT", VALUE, 1..10)
t=table(1..1000 as id, rand(100, 1000) as x)
dt = db.createTable(t, "dt").append!(t)
grant("user2", TABLE_READ, "dfs://dbMT/dt");

In DolphinDB, the shared in-memory tables are shared across all sessions, and the read and write permissions are managed in the access system. The access types for shared in-memory tables only support TABLE_READ and TABLE_WRITE.

Note:

• Only the table creator or administrator is allowed to set other users' access privileges on that table.
• If the table creator or administrator calls addAccessControl to restrict other users from accessing the shared table, other users can only access the table after being granted access privileges.
• If the table creator or administrator has set access privileges on the table for other users with grant/deny/revoke, access control will be automatically added. Users without granted privileges cannot access the table.

Examples:

Create an administrator admin1. Log in as admin1 to create a shared in-memory table st1:

login(`admin, "123456");
createUser("admin1","123456",,true)
login(`admin1, "123456")
share streamTable(1000:0, `time`sym`volume, [TIMESTAMP, SYMBOL, INT]) as st1

All users have the read and write privileges on the table st1:

createUser("user1","123456",,false)
login("user1","123456")
insert into st1 values(1970.01.01T00:00:00.001,`sym,1)
select * from st1

Grant user1 the read privilege on table st1:

login(`admin1, "123456")
grant("user1", TABLE_READ, "st1") 

After the grant operation is performed, access control is automatically added. Now user1 is granted the read privilege but not write privilege:

login("user1","123456")
select * from st1
insert into st1 values(1970.01.01T00:00:00.001,`sym,1)
// Error: No access to table [st1]

user1's privilege can be revoked:

login(`admin1, "123456")
revoke("user1", TABLE_READ, "st1")
login("user1","123456")
select * from st1 
// Error: No access to shared table [st1]

Use addAccessControl to restrict access to a shared in-memory table to the table creator and administrators.

share table(1:0, `time`sym`volume, [TIMESTAMP, SYMBOL, INT]) as st2
addAccessControl(st2)

Function views provide a flexible way to manage user access on databases and tables.

• Administrators can add or delete any function views. Users with VIEW_OWNER permission can add function views and delete the views they have created.
• Users with VIEW_EXEC permission can get the result of a function view even if they don't have access to the involved data.
• If a function view has the same name as a local function, the system will parse the function name as a local function.
• Some DDL and DML operations can be performed with only VIEW_EXEC privilege when included in function views.
• VIEW_EXEC can be applied to global (*), module level (<namespace>::*), or function view level. If functions of a module are added as views using addFunctionName(moduleName), the fully-qualified namespace can be used for specifying a module-level access control.

Example 1. Define a function view:

def countTradeAll(){  
    return exec count(*) from loadTable("dfs://TAQ","Trades")  
}
addFunctionView(countTradeAll)  
grant("user1",VIEW_EXEC,"countTradeAll")  

Log in as user1 to execute the function view:

countTradeAll()

In this example, though user1 does not have the privilege to access table "dfs://TAQ/Trades", user1 can still get the number of rows in the table with countTradeAll().

Example 2. Function views can take parameters. This example creates a function view to get the trades data of a specified stock on a specified date:

def getTrades(s, d){
	return select * from loadTable("dfs://TAQ","Trades") where sym=s, date=d
}
addFunctionView(getTrades)
grant("user1",VIEW_EXEC,"getTrades")  

Similarly, though user1 does not have the privilege to access table "dfs://TAQ/Trades", user1 can execute getTrades with specified stock symbol and date:

getTrades("IBM", 2018.07.09)

Example 3.

Declare a module myModule and define functions f1 and f2 within the module.

module dir1::myModule

def f1(){
    print "dir1::myModule::f1"
}
def f2(){
    print "dir1::myModule::f2"
}

After referencing the module with use, all functions within the module are added as function views.

use dir1::myModule
addFunctionView(moduleName="dir1::myModule")
getFunctionViews()

Grant VIEW_EXEC privilege on all function views within dir1::myModule to user1:

grant(userId="user1", accessType=VIEW_EXEC, objs="dir1::myModule::*")

Deny VIEW_EXEC privilege on all function views within dir1::myModule to user2:

deny(userId="user2", accessType=VIEW_EXEC, objs="dir1::myModule::*")

Note that the namespace must be specified to the module level. An error will be raised if the access control is set on dir1.

grant(userId="user1", accessType=VIEW_EXEC, objs="dir1::*")
// Error：The Module [dir1::*] does not exist.

Scheduled jobs are automated tasks to execute on a specific time or recurring basis.

• A user who creates a scheduled job does not require the access privileges on the involved objects. However, if the user does not have privileges to access the objects when the scheduled job is set to be executed, the scheduled job will not be executed.
• With command deleteScheduledJob, administrators can delete all scheduled jobs, while users can only delete scheduled jobs created by themselves.

login("user1","123456")  
def readTable(){  
	read_t1=loadTable("dfs://db1","t1")  
	return exec count(*) from read_t1  
}  
scheduleJob("readTableJob","read DFS table",readTable,minute(now()),date(now()),date(now())+1,'D');

In the example above, job readTable can be scheduled even if user1 does not have privilege to read table "dfs://db1/t1". When the job is set to be executed, however, if "user1" still does not have privilege to read table "dfs://db1/t1", the job will not be executed.

The scope of SCRIPT_EXEC and TEST_EXEC is global.

Executing function run, or executing scripts on clients requires SCRIPT_EXEC privilege:

login(`admin, `123456)
createUser(`user1, "123456");
grant(`user1,SCRIPT_EXEC)
login(`user1, "123456")
run("test.txt")

Executing function test, or executing unit tests on clients requires SCRIPT_EXEC privilege:

login(`admin, `123456)
createUser(`user1, "123456");
grant(`user1,TEST_EXEC)
login(`user1, "123456")
test("test.txt")

You can call grant and specify accessType = QUERY_RESULT_MEM_LIMIT to set the memory limit for the result of each query for a user, or accessType = TASK_GROUP_MEM_LIMIT to set the memory limit of a task group sent from the current node. It has similar functions with functions setMemLimitOfQueryResult and setMemLimitOfTaskGroupResult, but grant allows you to set the limit for a specific user (currently a group is not supported).

Set the memory limit of a query at 4 GB for user1:

grant("user1", QUERY_RESULT_MEM_LIMIT, 4)

Set the memory limit of a task group at 4 GB for user1:

grant("user1", TASK_GROUP_MEM_LIMIT, 4)

There are 2 ways to enable HTTPS:

• Add enableHTTPS=true in the configuration file of the cluster controller (controller.cfg).
• Add -enableHTTPS true in the command line when starting the cluster controller.

./dolphindb -enableHTTPS true -home master -publicName www.psui.com -mode controller -localSite 192.168.1.30:8500:rh8500 -logFile ./log/master.log

You need to install server authentication certificate at each server in DolphinDB for secure connections. There should be a certificate on the controller and each of the agent nodes. Data nodes use the certificate located at the agent node on the same server.