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.
Related
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
I am trying to grant access to a table from schema1 to schema2 (oracle10g).
I created a synonym on schema2:
CREATE SYNONYM schema2.table FOR schema1.table;
The synonym was created succesfully.
Then I tried to grant select on the same table:
grant select on schema1.table to schema2;
I got:
ORA-00942: table or view does not exist
This doesn't make sense to me. I was able to create the synonym but not the grant. What I am doing wrong?
I am not able to get the table from schema2:
select * from table;
ORA-00942: table or view does not exist
If I have "CREATE ANY SYNONYM| rights, I can create the synonym for the table in schema 1 in schema 2 without needing grants on the underlying objects. If I don't have rights on the schema1 table (GRANT WITH GRANT OPTION) to re-grant it to another user, then I can't also do the grant from this user.
Solution, log in as schema1 and do the grant there and then the synonym will work under schema2, or ensure that the user I AM logged in under has the rights to confer the grant on the schema1 object.
Per your comment:
Log in as schema1 and grant whichever operations you want schema2 to have on your table.
e.g)
SQL> GRANT SELECT, INSERT, UPDATE, DELETE on TABLE to SCHEMA2;
SCHEMA2 will then be able to see the table through its synonym, and be permitted those operations on it.
If SCHEMA2 is going to use this table in a view that it will then be granting select access to other schemas to use, then you need to add "WITH GRANT OPTION" to the initial grant from schema1 or schema2 will not be able to re-grant permissions on to other users.
You can create synonyms for objects that don't actually exist e.g.
create synonym flub for blib;
...so the fact that you were able to create a synonym does not mean the objects exists.
1/ How are privileges on synonyms and underlying objects related ? If one has rights on synonym, would he automatically has rights on the table and vice versa ?
Oracle says
When you grant object privileges on a synonym, you are really granting
privileges on the underlying object, and the synonym is acting only as
an alias for the object in the GRANT statement
which means privilege on synonym is enough. That will bypass table privilege.
Another source says that access right on table is enough and synonym privilege has no meaning.
Does it mean either privilege on the synonym or the underlying table is enough ?
2/ Is the behavior the same for private and public synonym. I haven't really seen an example of granting privileges on synonyms for a user to "see/access". How to grant privilege on private synonyms to a user ?
Both the Oracle docs and the message you referred to say exactly the same thing. Privileges are not granted on a synonym. When you attempt to grant privileges on a synonym the database actually performs the grant on the object referred to by the synonym. Thus, it makes no difference if the synonym is public or private because the actual grant is made on the object referred to by the synonym.
Best of luck.
EDIT
Let's demonstrate what happens:
-- Logged in as user BOB2
CREATE TABLE RPJ_TEST (N NUMBER);
SELECT *
FROM DBA_TAB_PRIVS
WHERE TABLE_NAME = 'RPJ_TEST';
-- the above statement returns no rows
CREATE SYNONYM RPJ_TEST_SYN -- create synonym
FOR RPJ_TEST;
SELECT *
FROM DBA_TAB_PRIVS
WHERE TABLE_NAME = 'RPJ_TEST';
-- the above statement returns no rows
GRANT SELECT ON RPJ_TEST TO BOB; -- grant on table
SELECT *
FROM DBA_TAB_PRIVS
WHERE TABLE_NAME = 'RPJ_TEST';
-- the above statement returns
GRANTEE OWNER TABLE_NAME GRANTOR PRIVILEGE GRANTABLE HIERARCHY
BOB BOB2 RPJ_TEST BOB2 SELECT NO NO
GRANT UPDATE ON RPJ_TEST_SYN TO BOB2; -- grant "on synonym" actually performs grant on table
SELECT *
FROM DBA_TAB_PRIVS
WHERE TABLE_NAME = 'RPJ_TEST';
GRANTEE OWNER TABLE_NAME GRANTOR PRIVILEGE GRANTABLE HIERARCHY
BOB BOB2 RPJ_TEST BOB2 SELECT NO NO
BOB BOB2 RPJ_TEST BOB2 UPDATE NO NO
Note that after the grant on the synonym RPJ_TEST_SYN the privileges granted on the table referred to by the synonym had been changed.
From Oracle Doc "A public synonym is owned by the special user group named PUBLIC and is accessible to every user in a database. A private synonym is contained in the schema of a specific user and available only to the user and to grantees for the underlying object."
With a public synonym PUBS on TABLE X of Schema B, User A can access User B's table X. With a private synonym PVTS on TABLE Y of Schema B, User A cannot access User B's table Y unless access is granted explicitly as mentioned above.
Check OracleDoc
My two cents:-
Suppose there is a table tab1 defined in abc_owner schema and its synonym is created in abc_user schema, then:-
Running a grant like this in the abc_user schema:-
GRANT SELECT ON tab1 TO def_owner;
might succeed or fail depending on the grants that abc_user has over the objects in abc_owner.
If it has only select grants, the above query will fail.
And then you will have to do it in the owner schema itself.
I have a schema A with a view VIEW. (A.VIEW)
This view reads the data from a table TABLE in schema B (B.TABLE).
I have to allow an user (C user) to select data from view A.VIEW:
select * from A.VIEW;
When the user makes this query, receive the message "ORA-01031 insufficient privileges".
I have already given the grant:
GRANT select on B.TABLE to A (with user sys);
GRANT select on B.TABLE to C;
GRANT select on A.VIEW to C;
So keep giving the same error.
I saw on the net that the problem is solved by assigning the grant:
GRANT select on B.TABLE to A WITH GRANT OPTION;
I don't want assign grant option: it's possible?
Thank you in advance
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.