I don't understand the difference between these two privileges.
I found these two explanations but it's not helping me.
CREATE TABLE -> Enables a user to create a table owned by that user.
CREATE ANY TABLE -> Enables a user to create a table owned by any user in the database.
If a user creates a table it's going to be owned by the user that created it right? I don't get it.
The CREATE TABLE privilege lets you create a table in your own schema. So user scott can do:
create table scott.mytable ( id number );
The CREATE ANY TABLE privilege lets you create a table in any schema in the database. So again, user scott can do:
create table hr.employees ( id number );
That is, make a table that belongs to someone else.
Related
How can I create a table of a user with sys? I want to give a table to an user but I want that this user can't alter the table.
I tried this:
CONNECT USER1/USER1;
CREATE TABLE Persons (
PersonID int,
LastName varchar(255),
FirstName varchar(255),
Address varchar(255),
City varchar(255)
);
But I want to create this table from sys user so user1 can't alter this table. How can I do that?
USER1 can alter a table in their schema, even if they don't have CREATE TABLE privilege.
As SYS:
grant create session to user1;
alter user user1 quota 100M on users ;
create table user1.t1 (id number);
Now connect as USER1. Both these statements will succeed:
insert into t1 values (1234);
alter table t1 add col1 varchar2(16);
In case it's not clear, USER1 cannot create tables. This statement will fail with ORA-01031: insufficient privileges...
create table t2(id number);
It's not clear exactly what you're trying to achieve, but the best way to control schemas is to separate schema owners from application users. Schema owners have objects but (usually) lack CREATE SESSION privilege, at least in production: their objects are deployed by power user accounts. Application users have CREATE SESSION and DML privileges on objects in the schema owner accounts but don't own any objects themselves, except maybe private synonyms and database links.
I use windows 7 and oracle 11g , so when i created user test and give an him create table privilege:
grant create table to test;
I notice that this user can also do select,insert,delete on the table that he created but i don't give him any object privileges.
is create table privilege mean all object privileges are granted?
Table owner can do everything with that table - all DML and DDL actions (selects, inserts, updates, deletes, alters, drops, ... everything).
If you want to let other users do something with your tables, then you'll have to grant those privileges to them.
In the documentation for all_constraints table it says that the "owner" column gives us information about "Owner of the constraint definition". But when examining the living example I found that to be false.
select user from dual; --gives EXAMPLE_USER
create table example_user.example_table(id number);
Now I will change user to SYS.
select user from dual --gives SYS
alter table example_user.example_table add constraint ex_constrain check(id > 10);
Now the best part:
select owner from all_constraints where constraint_name = 'EX_CONSTRAINT';
--gives EXAMPLE_USER and not SYS.
My question is simple: why?
Tested on: Oracle Database 11g EE 11.2.0.4.0
Well, SYS is special, it owns the database and can do anything.
If you wanted to do the same with another user (for example, SCOTT, and let it try to create constraint for EXAMPLE_USER's table), you'd fail unless privileged user grants SCOTT ALTER ANY TABLE system privilege. Doing so, that user will be able to alter any table (which belongs to any user), and that includes creating constraints.
If you'd want to create a primary key constraint, that privilege won't be enough - you'll need CREATE ANY INDEX privilege as well (as primary key creates index as well).
Just like CREATE ANY TABLE system privilege, which allows you to create a table in any other user's schema, but that table will then belong to the schema owner, the same goes for a constraint - yes, you created it in behalf of another user, but the constraint is still owned by the table owner, not the creator.
Therefore, dictionary isn't lying, it is you who misunderstood how it goes.
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.
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.