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
Related
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 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.
I have two users : Schema1 and Schema2
How to grant Create Table privilege On Schema2 to Schema1 ?
I have been turning around and I got confused.
I tried :
From Schema2 I tried,
GRANT CREATE TABLE TO SCHEMA1 WITH ADMIN OPTION;
But it seems like this grants Creating table to Schema1 in its own Schema and not in the Schema2.
Any ideas please ?
Thank you.
The only other way to allow a non-DBA user to create a table in another schema is to give the user the CREATE ANY TABLE system privilege.
This privilege can only be given to SCHEMA1 by a user having the CREATE ANY PRIVILEGE privilege.
You want to grant create ANY table:
grant create any table to schema1;
The any "modifier" allows to create tables in other than own schemas.
Better solution (minimizes the security threat that comes with CREATE ANY TABLE privilege...)
Create a procedure on schema2 that takes a table definition as a
"input" parameter (e.g. p_tab_def in varchar2(4000).
Inside put an execute_immediate(p_tab_def); statement. You MUST check the p_tab_def first in order to defend yourself from other DDL statements than
"CREATE TABLE [...]". (e.g. you could use a simple check by checking first two
words -> it must be "CREATE TABLE").
GRANT EXECUTE ON schema2.procedure_name TO schema1;
It's a simple concept ... I've used such concepts in my previous job.
When I try to execute a view that includes tables from different schemas an ORA-001031 Insufficient privileges is thrown. These tables have execute permission for the schema where the view was created. If I execute the view's SQL Statement it works. What am I missing?
Finally I got it to work. Steve's answer is right but not for all cases. It fails when that view is being executed from a third schema. For that to work you have to add the grant option:
GRANT SELECT ON [TABLE_NAME] TO [READ_USERNAME] WITH GRANT OPTION;
That way, [READ_USERNAME] can also grant select privilege over the view to another schema
As the table owner you need to grant SELECT access on the underlying tables to the user you are running the SELECT statement as.
grant SELECT on TABLE_NAME to READ_USERNAME;
Q. When is the "with grant option" required ?
A. when you have a view executed from a third schema.
Example:
schema DSDSW has a view called view_name
a) that view selects from a table in another schema (FDR.balance)
b) a third shema X_WORK tries to select from that view
Typical grants:
grant select on dsdw.view_name to dsdw_select_role;
grant dsdw_select_role to fdr;
But: fdr gets
select count(*) from dsdw.view_name;
ERROR at line 1:
ORA-01031: insufficient privileges
issue the grant:
grant select on fdr.balance to dsdw with grant option;
now fdr:
select count(*) from dsdw.view_name;
5 rows
Let me make a recap.
When you build a view containing object of different owners, those other owners have to grant "with grant option" to the owner of the view. So, the view owner can grant to other users or schemas....
Example:
User_a is the owner of a table called mine_a
User_b is the owner of a table called yours_b
Let's say user_b wants to create a view with a join of mine_a and yours_b
For the view to work fine, user_a has to give "grant select on mine_a to user_b with grant option"
Then user_b can grant select on that view to everybody.
If the view is accessed via a stored procedure, the execute grant is insufficient to access the view. You must grant select explicitly.
If the view is accessed via a stored procedure, the execute grant is insufficient to access the view. You must grant select explicitly.
simply type this
grant all on to public;
To use a view, the user must have the appropriate privileges but only for the view itself, not its underlying objects. However, if access privileges for the underlying objects of the view are removed, then the user no longer has access. This behavior occurs because the security domain that is used when a user queries the view is that of the definer of the view. If the privileges on the underlying objects are revoked from the view's definer, then the view becomes invalid, and no one can use the view. Therefore, even if a user has been granted access to the view, the user may not be able to use the view if the definer's rights have been revoked from the view's underlying objects.
Oracle Documentation
http://docs.oracle.com/cd/B28359_01/network.111/b28531/authorization.htm#DBSEG98017
you may also create view with schema name
for example create or replace view schema_name.view_name as select..