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.
Related
I'm using Oracle 11g(11.2.0.1.0). I created about 20 tablespaces and users. And the data came by [Tools] - [Database Copy] on Oracle SQL Developer.
Somehow I found that a user is using SELECT query on the table from another schema. I want to prevent it for security. How should I change my grant options?
I read "Oracle Database Security Guide 11g Release 2(11.2)", but couldn't find the solution clearly.
Here are my creating and granting queries.
create user [USER_NAME]
identified by [PASSWORD]
default tablespace [TABLESPACE_NAME]
temporary tablespace TEMP;
grant create session,
create database link,
create materialized view,
create procedure,
create public synonym,
create role,
create sequence,
create synonym,
create table,
drop any table,
create trigger,
create type,
create view to [USER_NAME];
alter user [USER_NAME] quota unlimited on [TABLESPACE_NAME];
And here is the SELECT result of session_privs on a user.
SQL> SELECT * FROM session_privs;
PRIVILEGE
--------------------------------------------------------------------------------
CREATE SESSION
CREATE TABLE
DROP ANY TABLE
CREATE SYNONYM
CREATE PUBLIC SYNONYM
CREATE VIEW
CREATE SEQUENCE
CREATE DATABASE LINK
CREATE ROLE
CREATE PROCEDURE
CREATE TRIGGER
PRIVILEGE
--------------------------------------------------------------------------------
CREATE MATERIALIZED VIEW
CREATE TYPE
13 rows selected.
I want to prevent a user from querying SELECT on other schemas.
For example, the following query
-- connected with USER1
SELECT *
FROM USER2.table1;
should make an error like:
ERROR: USER1 doesn't have SELECT privilege on USER2.
Edited:
Use appropriate terms (changed some words from tablespace to schema)
Add SELECT result of session_privs on a user
Add the method of how the data came by.
It was my fault. I missed that I had added some roles.
To copy data using Oracle SQL Developer, I added predefined roles to users. The roles were exp_full_database and imp_full_database.
According to Oracle Database Security Guide: Configuring Privilege and Role Authorization, exp_full_database contains these privileges:
SELECT ANY TABLE
BACKUP ANY TABLE
EXECUTE ANY PROCEDURE
EXECUTE ANY TYPE
ADMINISTER RESOURCE MANAGER
INSERT, DELETE, UPDATE ON SYS.INCVID, SYS.INCFIL AND SYS.INCEXP
and roles:
EXECUTE_CATALOG_ROLE
SELECT_CATALOG_ROLE
Those roles are not required now. So the answer is removing them from users.
REVOKE exp_full_database, imp_full_databsae FROM USER1;
And I get the result I wanted.
-- connected with USER1
SELECT * FROM USER2.TABLE1;
ERROR at line 1:
ORA-01031: insufficient privileges
I'm creating a USER on Oracle 12 c database, using TOAD.
After creating the TABLESPACE, I'm creating the USER. I'm a little confusing about the many ROLES and PRIVILEGES that can be given to a USER.
What are the minimum/standard roles and privileges a user must be given in order to perform CRUD operation and being able to 'edit' the database (create or delete table, DROP the schema ecc) from TOAD?
Thank you
It depends on what operations are you going to perform. If you want to work only with tables in your own db schema, then the following privileges are usually enough to start:
grant create session to <your_user>;
grant create table to <your_user>;
You have the default rights to insert/update/delete/select tables which you own.
Tablespace quota:
alter user <your_user> quota unlimited on <your_tablespace_name>;
It's better to set the default tablespace for the user. In this case you can omit the tablespace name in a create table statement.
alter user <your_user> default tablespace <your_tablespace_name>;
A link to the documentation - Privileges
Grant the user the following privileges:
CREATE SESSION (in order to allow the user to connect to the database)
INSERT
UPDATE
DELETE
SELECT
Use the below command to grant privileges to the user (you need to login as SYS or SYSTEM or another user that has GRANT privilege):
GRANT CREATE SESSION, SELECT, UPDATE, DETETE, INSERT TO user_name
Here's a suggestion you might (or might not) want to follow.
As a privileged user (such as SYS), check tablespaces available in your database. I'm using 11g XE (Express Edition) which shows the following:
SQL> show user
USER is "SYS"
SQL> select tablespace_name from dba_tablespaces;
TABLESPACE_NAME
------------------------------
SYSTEM
SYSAUX
UNDOTBS1
TEMP --> temporary
USERS --> my data
Now, create a user:
SQL> create user mdp identified by pdm
2 default tablespace users
3 temporary tablespace temp
4 quota unlimited on users;
User created.
Quite a long time ago, there were two popular predefined roles named CONNECT and RESOURCE which were granted some of the most frequent privileges so people just loved to grant those roles to newly created users.
Nowadays, you shouldn't be doing that: grant only minimal set of privileges your user might need. The first one is CREATE SESSION; without it, your user won't even be able to establish a connection.
SQL> grant create session to mdp;
Grant succeeded.
Then, you'll want to create some tables so - grant it:
SQL> grant create table to mdp;
Grant succeeded.
OK, let's connect as newly created user and do something:
SQL> connect mdp/pdm#xe
Connected.
SQL> create table test (id number);
Table created.
SQL> insert into test id values (1);
1 row created.
SQL> drop table test;
Table dropped.
SQL>
Nice; I can create tables, insert/update/delete/select from them. For beginning, that's quite enough. However, when it turns out that you'd want to, for example, create a view, it won't work until you grant it that privilege:
SQL> create view v_dual as select * From dual;
create view v_dual as select * From dual
*
ERROR at line 1:
ORA-01031: insufficient privileges
SQL> connect sys#xe as sysdba
Enter password:
Connected.
SQL> grant create view to mdp;
Grant succeeded.
SQL> connect mdp/pdm#xe
Connected.
SQL> create view v_dual as select * From dual;
View created.
SQL>
And so forth; don't grant anything just because you might need it - grant it if & when you need it. Especially pay attention to system privileges which can potentially be dangerous if you don't know what you're doing.
How to create database link to access dba tables from another user (which has no dba rights)? I want to take back up of sys.aud$ table in another tablespace which belongs to a user, but I am unable to access it.
you dont need to create a link. You my just grant select on this table/view to any user or create view and grant select on view. eg:
connect sys/<pass> as sysdba
grant select on sys.aud$ to NON_DBA_USER;
or create view with some restrictions:
create view view_to_grant_with_rest as select * from sys.aud$ where rownum < 11;
grant select on view_to_grant_with_rest to NON_DBA_USER;
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