I have my database on Oracle and I want to grant privileges to a certain group of users (for example, considering they're identfied by an id, users 1 to 9) and I also want to grant them access to a certain data (for example, a data which has a certain attribute).
Do I need to create a role in order for the group of users? And what do I have to do for only granting privileges to a certain data?
You don't have to create a role (as you can grant privileges directly to those users), but - role makes it simpler to maintain. So yes, I'd suggest you to create a role, grant privileges to that role, and then grant role to any user you want.
As of certain data: a simple option - if you think it is an option in your case - is to create a view whose WHERE clause restricts data only to specific set of rows. Then grant access on such a view to previously mentioned role (and users will "inherit" that privilege through it).
Related
There are 3 schemas: DEMO1, DEMO2, DEMO3
I want to grant DEMO1 permissions to perform all the operations on DEMO2 and not DEMO3.
ALL Operations means: Select, Update, Insert, Delete
How can I grant the privileges for that in Oracle SQL Developer?
You can't really do that. With many DDL privileges - as astentx pointed out - you either are constrained to what you own, or you can affect ANY table in the system, not just one other user. There's no middle ground unless you're also working with add-on enterprise products like Database Vault. If you're talking about DML (insert, update, delete of data), then grant the specific table privileges to a role and grant the role to DEMO1.
create role demo2_dml;
grant insert, update, delete on demo2.table_a to demo2_dml;
grant insert, update, delete on demo2.table_b to demo2_dml;
...
grant role demo2_dml to demo1;
alter user demo1 default role all;
Alternatively, if you must have DDL privileges as well, you could give DEMO1 proxy privileges to become DEMO2 and assume all of its privileges on its objects.
alter user demo2 grant connect through demo1;
Then connect using demo1[demo2] as the username, with demo1's password:
connect demo1[demo2]/demo1password#database_service
demo1 then becomes demo2 (without needing to know demo2's password) and can do anything demo2 would be able to do. demo1 would not have access to its own objects while doing this, however.
I need to move some views to a new user(newUser)
The views are to reference tables from the initial schema(originalUser.Table1).
There is a role with 'select' privilege on originalUser.Table1: role1.
If I grant 'role1' to 'newUser' I get ORA-00942 'table or view does not exist' when
create view newUser.View1 as select * from originalUser.Table1
But if I grant the privilege directly:
grant select on originalUser.Table1 to newUser
everything works fine and view gets created.
What can be wrong with the 'role' approach?
This is the documented behaviour; from the 19c create view section (emphasis added):
The owner of the schema containing the view must have the privileges necessary to either select (READ or SELECT privilege), insert, update, or delete rows from all the tables or views on which the view is based. The owner must be granted these privileges directly, rather than through a role.
Apart from the added complexity that role-granted privileges would add to potentially invalidating a view - if a role was removed from a user, all of the privileges under it, including in chained roles, would have to be evaluated to see if any table access was affected, and then which objects depended on that - roles can be disabled or require passwords etc.
This restriction is similar to the one that disables riles in any named PL/SQL block (procedure, function, package, trigger) created with definer's rights.
I want to get a a list of procedures in an Oracle database which a particular user has access to.
Lets say I have user scott which is owner of 10 procedures.
user scott has given all privileges to user xxx for some of these procedures.
Now is there any query through which I can find all such procedures which user 'xxx' can access?
There are multiple permissions that can be given, so the following query will depend on what you want to test,
but generally :
select * from all_procedures
Will provide the list of the procedures the current user has any permissions on (if to compile, and if to execute).
I am a huge noob with Oracle right now. I was asked to import two databases into Oracle. I succeeded...sort of...I think. So these databases were exported with the user and when I imported the databases it created the user and all of the tables were attached to that user. Same thing for the second database. Lets just call the user for the first import USER1 and for the second db import USER2. USER1 has its own tables and USER2 has its own tables.
I want to create a user that can see all of those tables. so I don't have to login to one to access and manipulate its data and the other to do the same. I would like to create a USER3 that can see and manipulate USER1 and USER2's tables associated with each. I have tried a number of ways and just cannot seem to get this to work. Any help would be greatly appreciated.
Thanks
To allow USER3 to query a table owned by USER1:
GRANT SELECT ON USER1.tablename TO USER3;
You must run this for each table individually.
Other grants that you may need are INSERT, UPDATE and DELETE, e.g. to grant full control:
GRANT SELECT, INSERT, UPDATE, DELETE ON USER1.tablename TO USER3;
When you login as USER3, to query the table you normally need to specify the schema, e.g.:
SELECT * FROM USER1.tablename;
If you want to avoid having to specify the schema each time, you can use synonyms, e.g.:
(login as USER3)
CREATE SYNONYM tablename FOR USER1.tablename;
Now you can login as USER3 and run this:
SELECT * FROM tablename;
"I just don't understand why I have to do all that."
Users - or schemas - are the means Oracle uses for organising applications and enforcing governance. In a well-design application it is extremely unlikely that one schema would need to grant every privilege on all its objects to another user. Oracle recommends a policy of granting the minimum necessary set of privileges to other users. Doing this requires us to make choices and write discrete statements to grant specific privileges on particular objects.
I have tables in Schema A. I created views in Schema B using the tables in schema A.
I want to grant permissions to a user to select the data from view in Schema B.
For this to work i know we have to enable the grant option on tables in Schema A to user B.
But I want to do it in a single script (This script has to be in schema B). Is there a way to do this using the user name/password of schema A.
It's not unusual to want to have a single script to deploy a change. The thing is, such a script needs to be run by a power user, because it needs to have system privileges at the ANY level. This usually means a DBA account, preferably an application account but otherwise SYSTEM or SYS.
So the script you want would look like this:
grant select on user_a.t23 to user_b
/
grant select on user_a.t42 to user_b
/
create view user_b.v_69 as
select t23.col1, t42.col2
from user_a.t42
join user_a.t23
on (t42.id = t23.id)
/
grant select on user_b.v_69 to user_c
/
A common scenario is that we have a suite of individual scripts which have been written to be run by different users but which we now need to bundle up into a single deployment. The original scripts don't contain the schema names, and there are many good reasons why we wouldn't want to hardcode them in the scripts.
One way to build that master script is to use change the CURRENT_SCHEMA syntax:
alter session set current_schema=USER_A
/
#run_grants_to_userb.sql
alter session set current_schema=USER_B
/
#create_view69.sql
#run_grants_to_userc.sql
We still need a DBA user to run the master script. One advantage of switching the current schema is that it allows us to deploy objects like database links, which through a quirk of syntax cannot have the schema name in their declaration. One gotcha is that the user doesn't change, so a script which employs the USER pseudo-column may produce unwanted results.
Simply Run the query
GRANT INSERT, SELECT, UPDATE, DELETE ON TABLE1 TO SCHEMA2;
Only by connecting as user A at some point. You can still do it in one script if you really want to:
connect userA/passwordA
grant select on my_table to userB;
connect userB/passwordB
create view my_view as select * from userA.my_table;
Of course now you have a script lying around which exposes two sets of user credentials to anyone who can read it. So something to think hard about before doing in production, for example.
If you want other users to be able to select from the view, you don't need to grant explicit permissions on userA.my_table to them; as long as the view owner can see the underlying table, other users just need to be able to see the view. Which is often kinda the point (or one of them) as you can restrict the view to only expose selected data from the underlying table to the rest of the world. I assume you have a reason for not creating the view in schema A.
I'm not sure if you're really asking about granting select to user B with admin option so that user B can then grant select on user A's table to other people. If that's possible, it doesn't sound like a good idea, and isn't necessary for the view to work.
Let user A grant select on his tables to B and include the 'grant option'.
As user A:
GRANT select ON table TO user_b WITH GRANT OPTION;
Let user B grant select on his views to user A and include the 'grant option'.
As user B:
GRANT select ON view TO user_a WITH GRANT OPTION;
As user A:
GRANT select on user_b.view TO user_c;
This allows user A to pass this grant on to other users.