What are roles and privileges to give a user in order to perform CRUD(on Oracle 12) - oracle

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.

Related

Accessing synonym of DB link object

Background:
We have database FIN having schema as FIN_DEV.
We have another database APP having schema APP_DEV.
A DB link is created in APP_DEV pointing to FIN_DEV
CREATE DATABASE LINK FINDEV_FIN
CONNECT TO FIN_DEV
IDENTIFIED BY <PWD>
USING 'FIN'
We are able to access the objects in FIN_DEV from APP_DEV using
CREATE OR REPLACE SYNONYM TBL_FINA FOR TBL_FINA#FINDEV_FIN
All good until this point.
Here comes the question:
Another schema INT_DEV in APP database needs to access SYNONYM TBL_FINA from INT_DEV.
Could you please let me know the best way to accomplish this?
Here's how; I don't have your users (and don't feel like creating them), so:
my remote database = orcl (it is your fin database)
user in my remote database = my_remote_user (it is fin_dev in your database)
user in my local database = scott (app_dev in your database)
it'll create a database link and a synonym
another user in my local database = mike (int_dev in your database)
In a remote database, I'm creating a table to mimic your situation:
SQL> create table tbl_fina (id number);
Table created.
SQL> insert into tbl_fina values (1);
1 row created.
SQL> commit;
Commit complete.
SQL>
Connecting to local database, creating a database link & a synonym:
SQL> show user
USER is "SCOTT"
SQL> create database link findev_fin
2 connect to my_remote_user
3 identified by its_password
4 using 'orcl';
Database link created.
SQL> -- Testing, whether the DB link works
SQL> select * From dual#findev_fin;
D
-
X
SQL> -- Creating a snynonym
SQL> create synonym tbl_fina for tbl_fina#findev_fin;
Synonym created.
SQL> select * from tbl_fina;
ID
----------
1
SQL>
So far, so good - this is what you currently have.
Now, let's allow another user - in my local database - to access that synonym. Straightforward solution is to grant select on it, right?
SQL> grant select on tbl_fina to mike;
grant select on tbl_fina to mike
*
ERROR at line 1:
ORA-02021: DDL operations are not allowed on a remote database
SQL>
Whooops! That won't work. A workaround is to create a view (on the synonym) and grant select on that view to mike:
SQL> create view v_tbl_fina as select * from tbl_fina;
View created.
SQL> grant select on v_tbl_fina to mike;
Grant succeeded.
SQL>
That works. Finally, connect as another user and select from the view (i.e. a synonym):
SQL> connect mike/pwd
Connected.
SQL> select * from scott.v_tbl_fina;
ID
----------
1
SQL>
For easier access - to avoid naming view owner (scott) - mike can now create its own synonym:
SQL> create synonym tbl_fina for scott.v_tbl_fina;
Synonym created.
SQL> select * from tbl_fina;
ID
----------
1
SQL>
Certainly, another option is to create a database link in my mike user, but that's kind of dangerous as database link allows its owner to do virtually anything in the remote database, as it is now identified by the remote username and its password.

How do I connect as newly created user through SQL Developer on Oracle Autonomous?

I have created a user(new_user) with a password.
I have granted create session to that user.
I still cannot connect to database as new_user.
ORA-01017.
I can connect as admin.
I can see the user(new_user) in the other users menu in SQL Developer.
When I go to create a table like CREATE TABLE new_user.SALES, I get ORA-01918: user 'NEW_USER' does not exist.
I can right-click and create a table.
I know I have the right password.
Sounds very much like the double quotes issue.
Here's how it is supposed to be done:
SQL> connect sys as sysdba
Enter password:
Connected.
SQL>
SQL> create user new_user identified by new_user
2 default tablespace users
3 temporary tablespace temp
4 quota unlimited on users;
User created.
SQL> grant create session, create table to new_user;
Grant succeeded.
SQL> connect new_user/new_user
Connected.
SQL> create table test (id number);
Table created.
This is what I suspect you did: drop the old user first:
SQL> connect sys as sysdba
Enter password:
Connected.
SQL> drop user new_user cascade;
User dropped.
SQL>
Now, start over. Pay attention to all double quotes in the following code:
SQL> create user "new_user" identified by new_user
2 default tablespace users
3 temporary tablespace temp
4 quota unlimited on users;
User created.
SQL> grant create session, create table to new_user;
grant create session, create table to new_user
*
ERROR at line 1:
ORA-01917: user or role 'NEW_USER' does not exist
SQL> grant create session, create table to "new_user";
Grant succeeded.
SQL> connect new_user/new_user
ERROR:
ORA-01017: invalid username/password; logon denied
Warning: You are no longer connected to ORACLE.
SQL> connect "new_user"/new_user
Connected.
SQL> create table new_user.test (id number);
create table new_user.test (id number)
*
ERROR at line 1:
ORA-01918: user 'NEW_USER' does not exist
SQL> create table "new_user".test (id number);
Table created.
SQL>
See? If you created it using double quotes, every time you reference it, you must use double quotes.
I suggest you get rid of them (double quotes) when working with Oracle. That includes users, table names, column names, procedure names, everything.

How could I prevent a user from querying SELECT on other schemas in Oracle?

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

Audting in Oracle 11g release 2

We have set audit_trail to DB, extended.I m trying to restrict the audit for specific users. But all users(objects) DML operations are auditing by default.
I tried to stop the auditing using all these statements:
SQL> NOAUDIT ALL;
Noaudit succeeded.
SQL> NOAUDIT ALL ON DEFAULT;
Noaudit succeeded.
SQL> NOAUDIT SESSION;
Noaudit succeeded.
SQL> noaudit select any table by X;
SQL> noaudit all by X;
But its still auditing all dml operations(for x schema also)
There are no audit policies and i see below output from below statement
SELECT * FROM DBA_PRIV_AUDIT_OPTS UNION SELECT * FROM DBA_STMT_AUDIT_OPTS;
null EXEMPT ACCESS POLICY By Access By Access
So i disabled it too
noaudit EXEMPT ACCESS POLICY;
Oracle 11g Release 2 Database is running on 64 bit CentOS.
Please let me know,is this default behavior of 11g database.If yes,Is there any way i can restrict it.
Your help is really appreciated.
Thank You!
By default database will record when it is stopped or started as well as record when a user logs on with either SYSDBA or SYSOPER privileges.
Oracle Database 11g audits the following privileges by default:
ALTER ANY PROCEDURE DROP ANY TABLE CREATE ANY PROCEDURE
ALTER ANY TABLE DROP PROFILE CREATE ANY LIBRARY
ALTER DATABASE DROP USER CREATE ANY TABLE
ALTER PROFILE DROP ANY PROCEDURE CREATE EXTERNAL JOB
ALTER SYSTEM EXEMPT ACCESS POLICY CREATE PUBLIC DATABASE LINK
ALTER USER AUDIT SYSTEM CREATE SESSION
GRANT ANY PRIVILEGE GRANT ANY ROLE CREATE USER
GRANT ANY OBJECT PRIVILEGE CREATE ANY JOB
Reference : https://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_auditing.htm#TDPSG50000
In your case you could check if fine grained auditing is turned on. You could check with the following SQLs.
SQL> SET lines 150
SQL> SELECT object_schema,object_name,policy_name,policy_column,enabled,sel,ins,upd,del FROM dba_audit_policies;
SQL> SELECT * FROM dba_audit_policy_columns;

Schema, User and functional Id in Oracle

I confused lot in oracle about schema, user and functional id. Let consider my two different cases
Case I :
Let us consider SCOTT#ORCL.If we think SCOTT is user. while creating user alone it ll create a schema. Correct me If i am wrong. In this case while we were creating SCOTT user alone SCOTT schema was created. Suppose If we create another schema say X . Is this possible to SCOTT user owns X schema ?
Case II :
Let us consider SCOTT#ORCL.If we think SCOTT is schema alone i-e which is created by schema command alone. If it is so then what is the use of schema w/o any user who is going to own it.
I heard oracle function ID is one which will connect several user/schema(i don't know whether I can put schema/user here ) in a data base. is there is difference b/w oracle functional ID with user/schema ?
Many people find this topic confusing, because we tend to bandy around USER and SCHEMA interchangeably, when they are in fact separate if related entities.
A schema is the collection of database objects owned by a user. When we create a user we create their schema at the same time. Initially their schema is empty.
It is easy to demonstrate that USER and SCHEMA are distinct, because we change the current schema in the session. This just means we can reference objects in another user's schema without prefixing them with the owner's name.
SQL> desc t1
Name Null? Type
----------------------------------------- -------- -------------
ID NUMBER
SQL> alter session set current_schema=APC
2 /
Session altered.
SQL> desc t1
ERROR:
ORA-04043: object t1 does not exist
SQL> sho user
USER is "X"
SQL>
In this case, either APC doesn't have a table called T1 or he hasn't granted it to X. The only way X can see her own table is to prefix it with her own name, or switch the current schema back to herself.
To answer your first question, the schema always has the same name as the user. So it is not possible for SCOTT to own schema X; schema X is owned by user X.
To answer your second question, it is impossible to create a schema without a user.
True, there is a CREATE SCHEMA command, but this requires the prior creation of the user. It is actually not creating a schema but creating several database objects. In effect it is more of a ADD OBJECTS TO SCHEMA command.
SQL> conn sys as sysdba
Enter password:
Connected.
SQL> create user x identified by x
2 default tablespace users quota 10m on users
3 /
User created.
SQL> grant create session, create table to x
2 /
Grant succeeded.
SQL> conn x/x
Connected.
SQL> create schema authorization x
2 create table t1 (id number)
3 create table t2 (id number)
4 /
Schema created.
SQL> select table_name from user_tables
2 /
TABLE_NAME
------------------------------
T1
T2
SQL>
The CREATE SCHEMA command is pretty limited: we can create tables, views and indexes, and grant privileges on objects. The advantage of it is simply that we can create several objects in a single transaction, so that all the creates are rolled back if one fails. This is not possible when we run each create statement separately.
Not sure what you're thinking off when you mention "function ID". It's not a standard piece of Oracle functionality.
This does not define the difference between an owner and schema.
But I have always struggled with the idea that I create N number of users....when I want each of these users to "consume" (aka, use) a single schema.
This guy shows how to do this (have N number of users...get "redirected" to a single schema.
I will paste his code as well, on the off-chance the URL link dies in the future.
http://www.oracle-base.com/articles/misc/schema-owners-and-application-users.php
He has a second "synonym" approach. But I am only pasting the CURRENT_SCHEMA version.
AGAIN, I take NO credit for this. I just hate when someone says "your answer is at this link" and BOOM, the link is dead. :<
......................................................
(from http://www.oracle-base.com/articles/misc/schema-owners-and-application-users.php)
CURRENT_SCHEMA Approach
This method uses the CURRENT_SCHEMA session attribute to automatically point application users to the correct schema.
First, we create the schema owner and an application user.
CONN sys/password AS SYSDBA
-- Remove existing users and roles with the same names.
DROP USER schema_owner CASCADE;
DROP USER app_user CASCADE;
DROP ROLE schema_rw_role;
DROP ROLE schema_ro_role;
-- Schema owner.
CREATE USER schema_owner IDENTIFIED BY password
DEFAULT TABLESPACE users
TEMPORARY TABLESPACE temp
QUOTA UNLIMITED ON users;
GRANT CONNECT, CREATE TABLE TO schema_owner;
-- Application user.
CREATE USER app_user IDENTIFIED BY password
DEFAULT TABLESPACE users
TEMPORARY TABLESPACE temp;
GRANT CONNECT TO app_user;
Notice that the application user can connect, but does not have any tablespace quotas or privileges to create objects.
Next, we create some roles to allow read-write and read-only access.
CREATE ROLE schema_rw_role;
CREATE ROLE schema_ro_role;
We want to give our application user read-write access to the schema objects, so we grant the relevant role.
GRANT schema_rw_role TO app_user;
We need to make sure the application user has its default schema pointing to the schema owner, so we create an AFTER LOGON trigger to do this for us.
CREATE OR REPLACE TRIGGER app_user.after_logon_trg
AFTER LOGON ON app_user.SCHEMA
BEGIN
DBMS_APPLICATION_INFO.set_module(USER, 'Initialized');
EXECUTE IMMEDIATE 'ALTER SESSION SET current_schema=SCHEMA_OWNER';
END;
/
Now we are ready to create an object in the schema owner.
CONN schema_owner/password
CREATE TABLE test_tab (
id NUMBER,
description VARCHAR2(50),
CONSTRAINT test_tab_pk PRIMARY KEY (id)
);
GRANT SELECT ON test_tab TO schema_ro_role;
GRANT SELECT, INSERT, UPDATE, DELETE ON test_tab TO schema_rw_role;
Notice how the privileges are granted to the relevant roles. Without this, the objects would not be visible to the application user. We now have a functioning schema owner and application user.
SQL> CONN app_user/password
Connected.
SQL> DESC test_tab
Name Null? Type
----------------------------------------------------- -------- ------------------------------------
ID NOT NULL NUMBER
DESCRIPTION VARCHAR2(50)
SQL>
This method is ideal where the application user is simply an alternative entry point to the main schema, requiring no objects of its own.

Resources