I have a grant alter sequence to a user. But I have to specify the schema name to alter the sequence otherwise it comes back with error sequence does not exist. Is it possible to do the grant in a way so I don't have to specify the schema name? I can do select/insert/update without specifying the schema name.
Name resolution and access privileges are separate concepts. The grant gives you permission to alter the schema, but you're still constrained by the namespace you're in. There are four ways to make a name in one schema resolve in another:
Reference the schema with the object name: select schema_name.sequence_name.nextval from dual;
Alter the current session to resolve names as if you were in the other schema: alter session set current_schema = schema_name;
Create a synonym for the object in the current schema: create synonym sequence_name for schema_name.sequence_name;
Create a public synonym for the object: create public synonym sequence_name for schema_name.sequence_name;
It sounds like you're connected to your database as a different user than the one that owns the sequence. In that case, you will need to preface the sequence with the schema, otherwise it's ambiguous as to what sequence you're talking about.
If you are connected to your database as the owning user, you do not need the schema qualifier:
SQL> create sequence foo;
Sequence created.
SQL> grant alter on foo to hr;
Grant succeeded.
you may:
ALTER SESSION SET CURRENT_SCHEMA myschema..
then you can reference all items without the qualifier.
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 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.
If I have a table sch1.tab1 is it possible to call it from schema/user sch2 just with
select * from tab1 (assume that we have all the privilegies)?
I am aware that in postgresql you can set the search path where db would look for tables which enables you to omit the schema when you are referencing a table but I do not know if this exists in oracle.
Thank you.
You can create a synonym, but you'd have to make one for each table you wanted to access; from sch2:
create synonym tab1 for sch1.tab1;
A more general method is to switch your current schema:
alter session set current_schema = 'SCH1';
You're still connected with your original user account and only have those privileges still, but you don't have to qualify objects in that schema any more. But now you would have to qualify any of your own tables (back in sch2), if you have objects in both schemas.
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.