This is hopefully a quick one, i'm new to oracle so need to check something before it bites me on the posterior
Ok i have a function that modifies a table
if i give the user permission to execute the function do they also need permission to update and insert in the table or is the fact they are approved to use the function enough?
the reason i ask is that the users need to edit these tables but only via approved functions which perform complex validation that can't be done easily via constraints
It depends on how you define your procedure, specifically the AUTHID property:
The AUTHID property of a stored PL/SQL unit affects the name resolution and privilege checking of SQL statements that the unit issues at run time.
By default the procedures are created with a AUTHID value of DEFINER (definer's right) ,the functions are executed as if the caller were temporarily given the rights of the definer.
With a value of CURRENT_USER, the AUTHID property will make the procedures check the privileges of the caller at run-time.
In your case, the scenario you describe would fit with the property value of DEFINER (the default): the users will only be able to call the procedures and functions without direct access to the underlying tables. A similar scenario is described in the documentation:
Scenario: Suppose that you must create an API whose procedures have unrestricted access to its tables, but you want to prevent ordinary users from selecting table data directly, and from changing it with INSERT, UPDATE, and DELETE statements.
Solution: In a special schema, create the tables and the procedures that comprise the API. By default, each procedure is a DR unit, so you need not specify AUTHID DEFINER when you create it. To other users, grant the EXECUTE privilege, but do not grant any privileges that allow data access.
Related
I'm surprised I haven't been able to find this question on the site already. Apologies if it turns out to be a duplicate!
In Oracle (10 upwards) is it possible for USER_A to deploy objects in USER_B's schema?
For example, assuming I am logged in as USER_B:
CREATE OR REPLACE PACKAGE user_a.my_example_pkg IS
PROCEDURE Make_Log;
PROCEDURE Init;
END user_a.my_example_pkg;
I get an ORA-1031: insufficient privileges response when I deploy.
I know that it is possible to log in as USER_A to deploy the package, and yes I can do that. But the point is that on my database, someone appears to have modified a package "across the schema" in this way. And I need to figure out how they did it!!
I'm fairly sure that the privilege exists, but I can't find what it is. Moreover, if there are many privileges which allow this to be done, it would be a bonus to get an exhaustive list of what those privileges are.
You'd want to look for the ANY privileges
CREATE PROCEDURE lets you create procedures in your schema. CREATE ANY PROCEDURE lets you create procedures in any schema.
CREATE TABLE lets you create tables in your schema. CREATE ANY TABLE lets you create tables in any schema.
CREATE VIEW lets you create views in your schema. CREATE ANY VIEW lets you create views in any schema.
For any of the CREATE privileges, there is a corresponding CREATE ANY privilege. Those ANY privileges are extremely powerful and really shouldn't be given to anyone other than a DBA since it would allow you to do things like create procedures owned by highly privileged users that can do anything a DBA could do.
We want to grant a user execute on a stored procedure which will access certain tables, but prevent that same user from performing a direct query on the same tables.
Here is our current model. User foo is the owner of the stored procedures. It has direct select, insert, update, and delete privileges on all the necessary tables. The stored procedures have been created with AUTHID CURRENT_USER. Foo grants execute on its stored procedures to user bar.
User bar calls the stored procedures via the grants above. By design, it has no ability to change the source code of any stored procedures. It has access via a role to the necessary tables.
So far, that works fine. Now we have a new requirement. A new user must be created that can execute the stored procedures, but cannot directly query against the tables (via SQLPlus, JDBC, ODBC, etc.)
I can't see any obvious way to implement this. All suggestions are welcomed.
If the procedures that foo owns were defined as authid definer, the default, then callers would not need privileges on the underlying tables in order to execute the stored procedures. Normally, that is how privileges are managed in Oracle. It is somewhat uncommon to use authid current_user stored procedures because that forces the caller to have privileges on the stored procedure in addition to privileges on the underlying table.
You'll either need to modify your existing procedures so that they are definer's rights stored procedures or you'll need to create a separate set of definer's rights stored procedures that you give the new user access to.
I have a situation in our Oracle environment where I would like to be able to grant select permissions to a certain user/group on all views in a particular schema.
I realize that I could write a dynamic statement to iterate over all the views in the schema and grant permissions to them individually as shown here but I would like to be able to have this apply to all views that exist in the schema now or in the future.
I was also contemplating the possibility of writing a DDL trigger that could monitor for the creation of new views but setting permissions in a trigger isn't something I've seen done before and doesn't seem like accepted practice.
Basically, is there a VIEW analog to the GRANT EXECUTE ANY PROCEDURE?
The EXECUTE ANY PROCEDURE grant allows a user to execute any procedure in any schema in the database, not just those in a particular schema. You can grant a user the SELECT ANY TABLE privilege-- that will allow the user to query any table or view in any schema in the database not just those in a particular schema. That's the analogous privilege, it just seems unlikely that either is really what you're after.
Since views should not be created dynamically, this sort of requirement would normally be handled by simply including the appropriate GRANT statements in the scripts that create the new views which get promoted up through the environments. Dynamically granting privileges is generally frowned upon because it generally implies that you have issues with your change control process that need to be addressed.
I have, for third party applications that insist on creating new objects periodically, created a DDL trigger that grants privileges on new objects. In order to do that, you would need to submit a job that actually does the GRANT. A GRANT is a DDL statement so it issues an implicit commit and implicit commits aren't allowed in triggers, you have to have a separate job that runs moments after the object is created. This means that you end up with a number of moving pieces that generally makes your environment more complex.
I need that the user does not have access to another scheme, but the stored procedure could access a different schema.
What you are describing is not possible.
If b.procedure can select, insert, update or delete on a.table, then anyone logged in as b could do so too.
What you should do instead is create procedure a.procedure and grant execute on a.procedure to b.
Privileges cannot be granted to objects, only to users or roles.
The way to implement this granularity of control is for the other schema to define the procedure which operates on its own tables. It then grants execute on the procedure to the other user. This is one valuable use case for procedures, encapsulating operations on schema objects.
The mechanism for controlling privileges in PL/SQL objects is the AUTHID. There are two options, CURRENT_USER and DEFINER. In this case you want to use the definer's rights, AUTHID DEFINER (which is the default). Find out more.
I have created a read only user A in Oracle DB. (who can access schema X but cannot alter anything) Then i am asked to give user A create table privilege on schema X.
However as far as i know, i can either give create any table privilege to user A or create table privilege. One of them is for creating table on his/her own schema, other one is for creating table on all schemas, which should not be preferred.
So i have given create any table privilege to user A and then created a trigger which prevents user A from creating a table on schemas other than X.
HOWEVER,
I needed to create the trigger as user A, and now user A can easily drop that trigger because A is the owner.
Is there any way i can prevent user A from dropping triggers even if he/she's the owner ?
As far as i experienced,user A does not need to have drop any trigger or administer database trigger privileges since trigger is already his/her own.
Is there any workaround for this ? Or should i search for an alternative way to give create table permission on other schemas.
Thank you in advance.
No, there is no way to prevent a user from dropping an object that it owns.
There's also no way to directly allow for user A to create objects in user X's schema, unless you start granting "ANY" privileges.
One possible workaround may be to create a stored procedure in user X's schema that will create objects in user X's schema (execute immediate) and grant EXECUTE privilege on said stored procedure to user A.
So, in this way, user A could do something like:
exec create_in_x_schema('create table blah(a number)');
And that procedure would just do an execute immediate on the string passed in.
A procedure that looks something like:
create or replace procedure create_in_x_schema(doit varchar2)
begin
execute immediate doit;
end;
/
ought to do it.
(Code is untested, but should give you some idea.)
Hope that helps.