I have following commands in a script :
ALTER SESSION SET CONTAINER = orclpdb
ALTER session set "_ORACLE_SCRIPT"=true;
CREATE PROFILE test_profile LIMIT password_life_time unlimited;
CREATE USER test IDENTIFIED BY test123
PROFILE test_profile
while dropping user using:
ALTER SESSION SET CONTAINER = orclpdb;
DROP USER test cascade;
I am getting :
ora-28014 cannot drop administrative users
My first concern is how this test user is getting administrative privilege.
Secondly is there anyway better way to do this.
The reason why the user is becoming ADMIN is due that the fact that you are using the underscore parameter _oracle_script=true
ORA-28014: Cannot Drop Administrative Users (Doc ID 1566042.1)
https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=267287602351459&id=1566042.1&_afrWindowMode=0&_adf.ctrl-state=w6ehg2ftt_53
As Oracle states in that document:
Users are considered administrative users when are created using the
script catcon.pl, or in that session the parameter "_oracle_script"
is set to TRUE.
You should not use it when you are creating users or anything else for that matter, unless you need to drop an administrative user, which in that case you have to.
To avoid this, when creating users avoid the use of the _oracle_script parameter altogether.
Related
I have created a audit policy "select_action_on_tables" by user_a.
create audit policy select_action_on_tables
actions select on user_a.test_table1;
And i grant "audit_admin" to user_b.
grant audit_admin to user_b;
but user_b unable to alter the "select_action_on_tables" with ORA-01031: insufficient privileges error.
alter audit policy select_action_on_tables add actions select on user_a.test_table2;
Do i miss any privileges need for user_b to alter an audit polity? Thank you.
AUDIT_ADMIN is a role, and roles are not activated by default. You either need to alter the user to make the role active by default, or alter the session to activate the role:
alter user user_b default role audit_admin [, role1, role2, ...];
alter user user_b default role all;
alter session set role audit_admin;
See documentation here:
https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/ALTER-USER.html#GUID-9FCD038D-8193-4241-85CD-2F4723B27D44
https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/SET-ROLE.html#GUID-863F9B6F-82B4-4C49-8E3A-3BA33AE79CAB
Also note that a role cannot be activated in existing sessions when first assigned. The designated user must start a new session in order to inherit the new privileges.
Flyway 7.7.3
I created a couple of repeatable migrations sql like below:
R__create_role.sql
-- Create role
CREATE ROLE ${roleName};
-- Grant privileges to role
GRANT SELECT ON ${tableName} TO ${roleName};
R__create_user.sql
-- Create user
CREATE USER ${newUser} IDENTIFIED BY ${userPwd};
-- Grant role to user
GRANT ${roleName} to ${newUser};
When I run flyway...migrate on this with supplied new user, I get below
CREATE USER TEST_USER_3 IDENTIFIED BY test3, Error Msg = ORA-01920: user name 'TEST_USER_3'
conflicts with another user or role name
BUT, the new user is created anyway.
NOTE1: I did make sure that TEST_USER_3 is not in the database before I run flyway...migrate. Also, I tried adding WHENEVER SQLERROR CONTINUE; after CREATE USER ${newUser} IDENTIFIED BY ${userPwd}; (because i know it creates the new user anyway), but I still get the error message.
NOTE2: I did the same thing in postgres (repeatable migrations for create role and user) and it works just fine.
Is there something wrong with the way I set up the queries ? or is this an issue with flyway-oracle? and is there a solution to this ?
is there a way to create a new admin user/role that can have access to all the existing tables.
If another user create a new table, the admin user should be able to also have permissions to the new table.
Right now, the only way is giving explicitly the list of the tables:
mclient -f "csv" -s "select name from sys.tables where system=false" | xargs -I '{}' mclient -s 'set schema "'$MONETDB_SCHEMA'"; grant select on "{}" to "pm-usecase"'
but if a new table is created by another user, then we need to grant access to the new table again.
We wondered the same thing but the only option is to make a role:
CREATE ROLE test_role;
Create a schema with the role authorisation present:
CREATE SCHEMA new_schema AUTHORIZATION test_role;
Grant the role to the users using the schema:
GRANT test_role TO test_user;
Now if the user test_user uses the set role test_role command in a sql session he will be able to access tables created by other users without having to be granted the privilege.
At the moment there seems to be no blanket option to make a user able to do this in all schema's. A solution could be to create all tables with one specific table role authorization.
There is a built-in role called sysadmin:
grant sysadmin to <user>
However, you would still need to set the role on your connection to activate the permissions.
Three days ago, I created another user, it's ok. Now I create another user, not working. I don't know what I missed.
This time I did:
CREATE USER TESTDB identified by N2dTlOBFRZ9x;
GRANT CONNECT, RESOURCE TO TESTDB;
GRANT CREATE SESSION TO TESTDB;
GRANT UNLIMITED TABLESPACE TO TESTDB;
GRANT CREATE TABLE to TESTDB;
GRANT CREATE VIEW to TESTDB;
I can create a view, named viewTest, save it.
TESTDB viewTest
select * from PRODDB.employee
Then open viewTest, it says insufficient privileges.
I have another user. let's call it PRODDB. This is online database
The user I created 3 days ago, is OKDB.
Today I created one another, TESTDB.
In OKDB, I created a view (viewTest) and I can open it.
select * from PRODDB.employee;
But in TESTDB, cannot open.
Thank you for the update! I believe this is a permissions issue.
In OKDB, I created a view and I can open it. select * from
PRODDB.employee;
But in TESTDB, cannot open.
So in this example, there are three users: 1. PRODDB, 2. OKDB, and 3. TESTDB.
The view is named Employee and was created under the PRODDB schema; PRODDB.EMPLOYEE.
If OKDB can query PRODDB.EMPLOYEE, one of two things have to be true. Either: 1. OKDB was granted privileges on PRODDB.EMPLOYEE directly (e.g. grant select on PRODDB.EMPLOYEE to OKDB;), or 2. OKDB has elevated privileges through a role that enables the user to query that view (e.g. grant DBA to OKDB, which will allow OKDB to query any table in the database.)
If TESTDB can't query the view, I would bet that the necessary privileges have not been granted to the user. To fix this, I would recommend checking the privileges and roles that have been granted to the OKDB user and then granting the same privilege(s) to TESTDB. If this is something work related, you may have to work with another DBA if you do not have permission to issue grants.
I have a schema that contains the vast majority of tables on my project, DEV2.
Additionally, I have a schema that contains oracle custom types used by DEV2: PUBLIC_TYPES.
I want to be able to create triggers on DEV2 that access the roles in PUBLIC_TYPES, but would prefer to do this with a role, so that when I create DEV3 (a clone of DEV2), I can just grant the role to DEV3 prior to compiling the triggers.
At the moment, if I perform the following:
grant all on public_types.type_name to DEV2;
and then (on the DEV2 user) I type:
desc public_types.type_name;
I get the proper description of the type.
However, if I instead do the following:
create role TABLE_PRIVS;
grant all on public_types.type_name_2 to TABLE_PRIVS;
grant table_privs to DEV2;
(and then switch to my DEV2 user, and desc)
desc public_types.type_name_2
I get
ORA-04043: object public_types.type_name_2 does not exist
What am I missing? I've granted the privilege to a role, and the role to a user. Does this work differently with types?
Thanks in advance!
Try to add role to user as default
grant table_privs to DEV2;
ALTER USER DEV2 DEFAULT ROLE table_privs;
otherwise you need to use SET ROLE