Access right on synonym and underlying table - oracle

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.

Related

Synonym privilege issue in oracle after creation?

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

Grant privileges to role query in Oracle not working

I am trying to run below query in oracle db .
a. GRANT UPDATE ON MIC_COMMON_AT.SHL_PRODUCERS TO MIC_READWRITE_AT;
This query does not give any error and says GRANT SUCCEEDED.
b. But when I run below query to check this grant in sys.all_tab_privs for the role, to which this grant should have been added, it gives me 0 rows
SELECT * FROM sys.all_tab_privs
WHERE GRANTEE = 'MIC_READWRITE_AT';
I am not sure why the required grant for role(MIC_READWRITE_AT) is not getting inserted in sys.all_tab_privs table (query b returning 0 rows) - even though grant query for that role seems to execute successfully without any error (query a).
The user with which I am executing this query has been given dba role as default role, as well as it has the system privilege of 'GRANT ANY OBJECT PRIVILEGE' AND "GRANT ANY PRIVILEGE'.
What am I missing here?
all_tab_privs only includes object grants for which the current user is the object owner, grantor, or grantee. It won't show you grants on objects in other schemas. Try using the dba_tab_privs view instead.

create Oracle db DBA Role with read only priviliges

I'm wondering if there's a way to set up a user with dba-like read-only privileges.
In my use-case, I'm trying to fetch some data from of schema from SYS.ALL_ARGUMENTS table.
I'm using this statements to create my user:
CREATE USER bbb IDENTIFIED BY bbb;
/
GRANT CREATE SESSION TO bbb;
/
grant select any table to bbb WITH ADMIN OPTION;
/
grant select on SYS.ALL_ARGUMENTS to bbb;
when I try to run the following statement to fetch data of HR schema:
SELECT * FROM SYS.ALL_ARGUMENTS a WHERE a.OWNER = 'HR' ORDER BY SEQUENCE;
I get nothing. If I set my user with DBA role or IMP_FULL_DATABASE role, i manage to get this data but then my user has privileges I don't want him to have.
Privilege SELECT ANY TABLE does not include dictionary views. Run
GRANT SELECT ANY DICTIONARY TO bbb;
in order to grant full read access.

Why I can create a synonym but no give grant select to the same table?

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.

Grant Privileges and Create Public Synonym in Oracle

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.

Resources