Say UserA created an Oracle 11g procedure named SomeProc, SomeProc perform DML/DDL queries on UserB schema, how to accomplish this without granting UserA access on UserB needed objects? example:
CREATE OR REPLACE Procedure UserA.SomeProc IS
BEGIN
UPDATE UserB.SomeTable SET SomeField = 1;
END;
Running the above example will throw exception asking to grant UserA updating UserB table.
The idea of my question is, I don't want UserA to be able to SELECT TABLE from UserB schema directly from application code, instead, UserA should only be able to execute his own Procedure where that procedure itself is the one who can access UserB objects, it is a sort of security approach we need to avoid UserA from running his own custom queries from application code.
without granting UserA access on all UserB objects
Lucky you, that's exactly how it works. You can't grant privileges on all objects; there's no (for example)
grant select on all userA tables to userB;
You have to grant privileges on every object separately.
Therefore, the answer to your question is simple: grant only required privileges on desired objects to another user, e.g.
grant select on dept to userb;
grant select, insert, update on emp to userb;
Related
There are 3 schemas: DEMO1, DEMO2, DEMO3
I want to grant DEMO1 permissions to perform all the operations on DEMO2 and not DEMO3.
ALL Operations means: Select, Update, Insert, Delete
How can I grant the privileges for that in Oracle SQL Developer?
You can't really do that. With many DDL privileges - as astentx pointed out - you either are constrained to what you own, or you can affect ANY table in the system, not just one other user. There's no middle ground unless you're also working with add-on enterprise products like Database Vault. If you're talking about DML (insert, update, delete of data), then grant the specific table privileges to a role and grant the role to DEMO1.
create role demo2_dml;
grant insert, update, delete on demo2.table_a to demo2_dml;
grant insert, update, delete on demo2.table_b to demo2_dml;
...
grant role demo2_dml to demo1;
alter user demo1 default role all;
Alternatively, if you must have DDL privileges as well, you could give DEMO1 proxy privileges to become DEMO2 and assume all of its privileges on its objects.
alter user demo2 grant connect through demo1;
Then connect using demo1[demo2] as the username, with demo1's password:
connect demo1[demo2]/demo1password#database_service
demo1 then becomes demo2 (without needing to know demo2's password) and can do anything demo2 would be able to do. demo1 would not have access to its own objects while doing this, however.
I have worked on PostgreSQL, which has a concept of public schema. By default all objects goes into public schema, if no schema is defined explicitly. This allows all the users in that database to access all objects in public schema.
I want to know what is the equivalent of this in Oracle DB. How do I create objects using ADMIN user and make them available to all the users in that db. Currently, objects created using ADMIN are available to ADMIN user only. We have to explicitly grant permissions to other users to objects in ADMIN schema.
We have to explicitly grant permissions to other users to objects in ADMIN schema.
Exactly, that's how Oracle works.
Though, you don't have to do it "manually". A good option is to create a role, then grant privileges on tables to that role, and - finally - grant role to every user you want. What's good in it? If new user is created, just grant the same role to it and everything works.
Also, you can write a script to do the job for you. If you're connected as ADMIN, then e.g.
SQL> begin
2 for cur_r in (select table_name from user_tables) loop
3 execute immediate 'grant select on ' || cur_r.table_name ||' to admin_role';
4 end loop;
5 end;
6 /
PL/SQL procedure successfully completed.
SQL>
In a matter of seconds everything is done.
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.
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.
In Oracle you can grant system privileges like
GRANT CREATE TRIGGER TO MY_USER;
But you can as well grant privileges this way
GRANT CREATE ANY TRIGGER TO MY_USER;
As system privileges are system-wide, where is the difference between the 2 statements above. Does the additional ANY-keyword grant anything else more than system? If I add a Grant ... ON SCHEMA ... it's no system privilege anymore, is it?
Assumption is that there are multiple schemas/objects in the database from different users one cannot access without these privileges.
EDIT:
SELECT *
FROM DBA_SYS_PRIVS
WHERE grantee = 'MY_USER';
returns
GRANTEE PRIVILEGE
------------ -------------
MY_USER CREATE ANY TRIGGER
MY_USER CREATE TRIGGER
(I omitted the columns ADMIN_OPTION and COMMON)
And the result is the same when querying this with MY_USER, MY_USER2 or any other user. I see no connection to a schema here. And it is also possible to only have the CREATE ANY TRIGGER-privilege.
In most cases, the trigger owner is also the owner of the table (or view) on which the trigger is based. In those cases, the table owner, with CREATE TRIGGER can create create triggers on their own table.
CREATE ANY TRIGGER allows the user to create a trigger owned by any user on any table. It is a big security hole because they can create a trigger owned by a privileged user on a table that they own or can insert into. Because they can insert into that table, they can force the trigger to execute and the trigger executes with the privileges of the trigger owner. The effect is that a user with CREATE ANY TRIGGER privilege can create and execute code as a privileged user (similar to having CREATE ANY PROCEDURE plus EXECUTE ANY PROCEDURE).
Limit to as few as people as possible and audit appropriately.
The first statements grants the right to create triggers in the schema of MY_USER. The owner will always by MY_USER.
The second statements grants the right to create triggers in ANY schema. The owner of the trigger can then be any user.
The last option is usually not wanted because it gives user MY_USERS the possibility to corrupt the data model.