Dameng user permission configuration, Dameng, permissions, user permissions, configuration

All the content here is based on the following version and may be changed later with the version.

select * from v$version;
--DM Database Server x64 V7.6.0.96-Build(2018.09.19-97292)ENT

Notice

1. A role is a collection of a series of permissions, which is a convenient way for users to operate, because many permissions (such as query permissions for many tables, or other permissions, etc.) are packaged into a role, and all these permissions will be granted to a user later. Only [grant
   role to user] is required.

2. Dameng database has three roles by default: DBA, RESOURCE, and PUBLIC.

3. In the DBA role, it is enough to have all the permissions of the system. If the DBA is granted, it is the boss of the database system.

4. In the RESOURCE role, it corresponds to all the permissions under the user's own user. If RESOURCE is granted, the user can operate as much as he wants under his own user.

Therefore, correspondingly, we are divided into three situations here:

Scenario 1:

create user user_name_1 identified by passwd123456;– do nothing else

Scenario 2:

create user user_name_2 identified by passwd123456; grant resource to user_name_2;– do nothing else

Case 3:

create user user_name_3 identified by passwd123456; 
grant dba to user_name_3;

Scenario 4:

create user user_name_4 identified by passwd123456; 
grant resource any table to user_name_4; 
grant select any table to user_name_4;

illustrate:

Scenario 1: 1. In addition to being unable to create new tables under his own user, this user can add, delete, and modify existing tables, including deleting existing tables. Everything can be done. 2. Of course, other users can’t do anything (queries can’t be done, and the operation will report an error without permission) 3. What should I do if I want to create a new object for this user? Of course, I can only use other users with permissions (generally is an administrator) just create a new object under this user, so that the target user can query new things.

The key point is that this user can do things under his own user, but cannot create new objects. ——There are indeed scenes that require this.

Situation 2: Under this user, you can do anything under your own user; under other users, you can't do anything.

Situation 3: This user can do whatever he wants on the database (under all users), after all, it is called: with DBA authority. Therefore, this permission is generally not given.

Situation 4: This is to construct a scenario of querying users. He can do whatever he wants under his own user, and at the same time, he can query the data of the whole database, but he cannot add, delete, or modify the data under other users.

Summarize:

1. In general, case 2 is what we need; case 4 is what we often need. If we need to create a new user and can only query specific tables, please refer to the second half of this article.

2. We can check the specific permissions of the three roles (DBA RESOURCE PUBLIC) through the system table: select * from DBA_SYS_PRIVS ;

[DM-User Permission Configuration] How to control permissions so that a user can only access one table and cannot see tables in other modes? Database user permission control The table control seen by the manager.rst ¶

Symptom

Notice

If you want to give a user the query permission of the whole database, grant select any table to your_username;

If you only want to grant permission to a specific table, please refer to the following text.

It is hoped that a user can only see the tables in his own mode, but not the tables in other modes

Or control that a user can only see the authority to make the table.

How should permissions be configured?

—— The core isrevoke public from user_test

Approach

Here is an example: How to create a user that can only see specified tables.

– This script executes with sysdba

create table sysdba.test (v1 int);
drop user test_u;
create user test_u identified by 111111111;
revoke public from test_u;

grant select on v$instance to test_u;
grant select on V$MPP_CFG_ITEM to test_u;
grant select on V$DATABASE to test_u;
grant select on V$DM_INI to test_u;
grant select on V$VERSION to test_u; 
-- weblogic 11g test need  2019/9/11 16:59:22

Remarks: If it is dmserver in 2017, skip these steps and directly
grant select on the table you want it to be able to query to aim_user_name;
that’s all right
because, in previous versions, the authority of the system dictionary is the built-in user sys of dmserver,
sysdba It can't (and can't be) controlled, that is, sysdba can't revoke and grant the permissions of dictionary tables,
sysdba doesn't care (and can't manage) the permissions of dictionary tables

grant select on test to test_u;

At this point, use test_u to log in to the manager, and you can see the test table in the left navigation bar

Here is the relevant example

one reason to do it

-- sysdba 跑的
create table test_1 (v1 int);
insert into test_1 select level connect by level<=100;

create view test_v as select v1 from test_1 where v1<3;

grant select on test_v to test_u;
-- test_u 查的
select * from sysdba.test_v; --ok
select * from sysdba.test_1; -- 没有\[TEST_1\]对象的查询权限

…Notice::

Select table and select any table include insert delete, etc. All descriptions without any are the permissions under your own user.

This document was generated on 2021-05-12 at 23:50.

Reprinted to: https://dms1101.gitee.io/dms/manager%EF%BC%88%E5%90%ABsql%E7%9A%84%E4%BD%BF%E7%94%A8%EF%BC %89%E9%83%A8%E5%88%86/%E3%80%90DM-%E7%94%A8%E6%88%B7%E6%9D%83%E9%99%90%E9%85 %8D%E7%BD%AE%E3%80%91%E6%9D%83%E9%99%90%20%E6%8E%A7%E5%88%B6%20%E5%A6%82%E4 %BD%95%20%E8%AE%A9%20%E4%B8%80%E4%B8%AA%20%E7%94%A8%E6%88%B7%20%E5%8F%AA%E8 %83%BD%20%E8%AE%BF%E9%97%AE%E4%B8%80%E4%B8%AA%E8%A1%A8%20%E4%B8%94%20%E7%9C %8B%E4%B8%8D%E5%88%B0%20%E5%85%B6%E4%BB%96%20%E6%A8%A1%E5%BC%8F%20%E4%B8%8B %E7%9A%84%20%E8%A1%A8%20%E6%95%B0%E6%8D%AE%E5%BA%93%20%E7%94%A8%E6%88%B7%20 %E6%9D%83%E9%99%90%E6%8E%A7%E5%88%B6%20manager%20%E7%9C%8B%E5%88%B0%E7%9A%84%E8%A1 %A8%20%E6%8E%A7%E5%88%B6.html