I just wondering if there any option to grant permission to create synonyms on different schema without giving 'ANY' option. I just want to narrow down the grant to provide permission with what is required for security purpose.
We have created a schema name A which related to application product. But the application suppose to access the object through another (login) schema B. We have granted resource to schema A so schema A owner can creates its own objects. What grant syntax i need to use to grant Schema A to create synonyms on schema B, so it can create synonyms.
End result should be as below and can be created by schema owner A without interference of DBA
B.b_synonym maps to A.b_object
You need the CREATED ANY SYNONYM privilege to do that as A, therefore
GRANT CREATE ANY SYNONYM TO A;
EDIT: To avoid the ANY privilege, do this:
a) as A:
GRANT SELECT ON mytable1 TO B;
GRANT SELECT, INSERT, UPDATE, DELETE ON mytable2 TO B;
b) as B:
CREATE SYNONYM a_mytable1 FOR A.mytable1;
CREATE SYNONYM a_mytable2 FOR A.mytable2;
You can't grant privileges that only apply to one other schema. You would have to grant ANY - even if temporarily, e.g. during the creation/modification of the main A schema, to reduce the security impact - and create all the synonyms in the other B user's schema while you had the privileges. Otherwise user B would have to create the synonyms itself; or user A could create public synonyms.
As an alternative to having any synonyms, you could have user B switch to schema A with:
alter session set current_schema = A;
They could then refer to A's objects without having to prefix them with the schema name, though they then couldn't see any objects in their own schema without prefixing those instead - it doesn't sound like B will have objects but hard to tell.
You can also automate that schema switch via a logon trigger:
create or replace trigger ramread_logon_trigger
after logon on database
begin
if user = 'B' then
execute immediate 'alter session set current_schema = A';
end if;
end;
/
If you actually have multiple users you can use a role instead, and switch schema for any user that has that role, by testing with dbms_session.is_role_enabled. The same role could be granted the necessary permissions to access A's objects, which you will need to grant somehow - a synonym doesn't itself give any access privileges.
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 have a parent table in schema A, when I try to select the synonym from schema B then it gives me error 'ORA-01031: insufficient privileges'. Please suggest what is the issue here? patrent table is in schema A and my synonym is in schema B.
Just creating the synonym doesn't grant any privilege on the underlying object. You need to explicitly grant required privileges on the object. Also, privilege are actually not granted on a synonym, the actual grant is made on the object referred to by the synonym.
To grant select on the table, do:
GRANT SELECT ON table TO SCHEMA2; -- do this in SCHEMA1
In Oracle you can grant system privileges like
GRANT CREATE TRIGGER TO MY_USER;
But you can as well grant privileges this way
GRANT CREATE ANY TRIGGER TO MY_USER;
As system privileges are system-wide, where is the difference between the 2 statements above. Does the additional ANY-keyword grant anything else more than system? If I add a Grant ... ON SCHEMA ... it's no system privilege anymore, is it?
Assumption is that there are multiple schemas/objects in the database from different users one cannot access without these privileges.
EDIT:
SELECT *
FROM DBA_SYS_PRIVS
WHERE grantee = 'MY_USER';
returns
GRANTEE PRIVILEGE
------------ -------------
MY_USER CREATE ANY TRIGGER
MY_USER CREATE TRIGGER
(I omitted the columns ADMIN_OPTION and COMMON)
And the result is the same when querying this with MY_USER, MY_USER2 or any other user. I see no connection to a schema here. And it is also possible to only have the CREATE ANY TRIGGER-privilege.
In most cases, the trigger owner is also the owner of the table (or view) on which the trigger is based. In those cases, the table owner, with CREATE TRIGGER can create create triggers on their own table.
CREATE ANY TRIGGER allows the user to create a trigger owned by any user on any table. It is a big security hole because they can create a trigger owned by a privileged user on a table that they own or can insert into. Because they can insert into that table, they can force the trigger to execute and the trigger executes with the privileges of the trigger owner. The effect is that a user with CREATE ANY TRIGGER privilege can create and execute code as a privileged user (similar to having CREATE ANY PROCEDURE plus EXECUTE ANY PROCEDURE).
Limit to as few as people as possible and audit appropriately.
The first statements grants the right to create triggers in the schema of MY_USER. The owner will always by MY_USER.
The second statements grants the right to create triggers in ANY schema. The owner of the trigger can then be any user.
The last option is usually not wanted because it gives user MY_USERS the possibility to corrupt the data model.
I have Views in Schema A and I want to create a Synonym for these views in Schema B.
Could you please help me write a query for Granting the role and creating a synonym?
From user A, you only need to grant SELECT privilege to user A's views to user B
GRANT SELECT ON A.viewname1 TO B;
GRANT SELECT ON A.viewname2 TO B;
...
From B, creating synonyms allows reference to user A's views without the schema prefix ("A.").
CREATE SYNONYM viewname1 FOR A.viewname1;
CREATE SYNONYM viewname2 FOR A.viewname2;
...
It should now be possible for user B to select from those views like this:
SELECT * FROM viewname1;
Note that a user can only use CREATE SYNONYM if they have the CREATE SYNONYM privilege.
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.