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
Related
im using oracle db v21c , after trying to create a role student with privs 'create session , create table , create view ' a granted that role to a user 'user3' but when trying to connect with that user i got ora-01045. i checked that privs granted to that role and everything seems normal , i have tried using granting the role the privileges with admin option and nothing happens . I used select * from dba_sys_privs where grantee='student' and all seems good . The role is created with system and so the user because at first i was trying to create the role with scott , but get an error insufficient privileges, but scott have the privilege to create role.
Roles are not active by default. You must either alter the user to set a default role (and then login again), or alter the user's current session to set a current role:
alter user user3 default role all;
or
set role student;
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.
I have created a new user using the below in sql developer (Oracle 11g). I have only two tables titled FEED_DATA_A and FEED_DATA_B that I want this user to be able to select, update and insert into. Can someone help me understand the SQL to create the proper privileges to accomplish that? I'm currently logged in as the system user.
CREATE USER "USER_A" IDENTIFIED BY "test123";
If you want to grant the privileges directly to the user
GRANT select, update, insert
ON table_owner.feed_data_a
TO user_a;
GRANT select, update, insert
ON table_owner.feed_data_b
TO user_a;
More commonly, though, you would create a role, grant the role to the user, and grant the privileges to the role. That makes it easier in the future when there is a new user created that you want to have the same privileges as USER_A to just grant a couple of roles rather than figuring out all the privileges that potentially need to be granted. It also makes it easier as new tables are created and new privileges are granted to ensure that users that should have the same privileges continue to have the same privileges.
CREATE ROLE feed_data_role;
GRANT select, update, insert
ON table_owner.feed_data_a
TO feed_data_role;
GRANT select, update, insert
ON table_owner.feed_data_b
TO feed_data_role;
GRANT feed_data_role
TO user_a
Everytime I create a new view I have to change the permissions to all, and it's quite painfully to do a lot of times the same thing.
I also ask if is possible to change some default options in the database I create the view in order the permissions to be set to public.
Thanks
It sounds like you are using SQL naming. Use System naming instead, this will grant public authority according to the QCRTAUT system value. See Birgitta Hauser's article.
System naming has the added advantage of using the job's library list to resolve unqualified object references. By not hard-coding schema names, but allowing the system to find them according to the library list, enabling your code to work in different environments (ex. development, testing, training, production) without modifying the code, simply by running with a different library list. Therefore you can install code into production exactly the same code that was tested.
The following is from the V6R1 documentation:
Authorization
The privileges held by the authorization ID of the statement must
include at least one of the following:
The privilege to create in the schema. For more information, see
Privileges necessary to create in a schema.
Administrative authority
The privileges held by the authorization ID of the statement must
include at least one of the following:
The following system authorities: *USE to the Create Logical File
(CRTLF) CL command *CHANGE to the data dictionary if the library
into which the view is created is an SQL schema with a data dictionary
Administrative authority
The privileges held by the authorization ID of the statement must also
include at least one of the following:
For each table and view referenced directly through the fullselect,
or indirectly through views referenced in the fullselect: The SELECT
privilege on the table or view, and The system authority *EXECUTE on
the library containing the table or view Administrative authority
View ownership: If SQL names were specified:
If a user profile with the same name as the schema into which the
view is created exists, the owner of the view is that user profile.
Otherwise, the owner of the view is the user profile or group user
profile of the job executing the statement.
If system names were specified, the owner of the view is the user
profile or group user profile of the job executing the statement.
View authority:
If SQL names are used, views are created with the system authority of
*EXCLUDE on *PUBLIC. If system names are used, views are created with the authority to *PUBLIC as determined by the create authority
(CRTAUT) parameter of the schema.
If the owner of the view is a member of a group profile (GRPPRF
keyword) and group authority is specified (GRPAUT keyword), that group
profile will also have authority to the view.
The owner always acquires the SELECT privilege WITH GRANT OPTION on
the view and the authorization to drop the view.
The owner can also acquire the INSERT, UPDATE, and DELETE privileges
on the view. If the view is not read-only, then the same privileges
will be acquired on the new view as the owner has on the table or view
identified in the first FROM clause of the fullselect. These
privileges can be granted only if the privileges from which they are
derived can also be granted.