When executing a PL/SQL block, any privileges granted to roles are ignored. Instead you must give specific users specific grants to run it. If I want to give DBAs access to a package or a function or a procedure, I can't give the DBA role a grant. I have to give a grant to each user in the DBA role, I have to remove the user's grant if they cease to be a DBA, and I have to add the grant to any new DBA.
I find this very hard to maintain.
My question is why does PL/SQL work this way? What design considerations did Oracle make to decide that this is how Roles and PL/SQL should work together? I've been unable to find an answer that isn't "that's just the way it is".
I think you may be fighting over Invokers rights vs Definers rights.
From Oracle docs:
During a server call, when a DR unit is pushed onto the call stack,
the database stores the currently enabled roles and the current values
of CURRENT_USER and CURRENT_SCHEMA. It then changes both CURRENT_USER
and CURRENT_SCHEMA to the owner of the DR unit, and enables only the
role PUBLIC. (The stored and new roles and values are not necessarily
different.) When the DR unit is popped from the call stack, the
database restores the stored roles and values. In contrast, when an IR
unit is pushed onto, or popped from, the call stack, the values of
CURRENT_USER and CURRENT_SCHEMA, and the currently enabled roles do
not change
So if you want Oracle to "respect the privileges granted by roles", then perhaps you want to use Invokers rights ( AUTHID CURRENT_USER clause)
It's probably a combination of laziness and the SET ROLE command.
I disagree that it's not allowed because of complex dependencies. Oracle already manages complex dependencies. And in 12c it is possible to grant a role to an object.
I think the real reason why objects don't inherit the roles of the user is because of the SET ROLE command. It's possible for a user to be assigned a role but to turn it on and off within a session. That's a silly feature and I've never seen it used. But theoretically it would require recompiling within the same session or transaction, which would be really confusing.
Otherwise if you drop a role then the PL/SQL package would become INVALID in some cases (without having the option to re-compile).
DROP ROLE ... is a DCL (Data Control Language) statement. Looks like Oracle decided: "A PL/SQL package shall not become INVALID by a DCL statement"
Maybe I am not understanding something correctly here, because I have done what you say can't be done. In fact, the Oracle documentation says it can be done. Look at the section on Procedure Security in this document. (#ibre5041)Nothing would have to be recompiled because the procedures run under the owner's privileges. The user's (or his roles') privileges are only checked for whether they are allowed to run the procedure.
What am I missing?
I'm think it is some historical heritage. When changing ROLE's object privs Oracle would have re-compile a lot of PL/SQL stored code. PS: you can also create something called "SCHEMA".
See CREATE SCHEMA statement.
Related
One schema in our database has ACL privilege to an URL and can send requests to this URL. If I now write a procedure in this schema that sends the request and grants a different schema the option to execute this procedure, will it work or does the second schema also need the ACL privilege?
I am asking to plan the necessary approach to this topic since I need to write an package in the second schema.
If I understood it correctly it seems like that by default the authid property is set to definer rights. This should mean that it executes with the privileges of the owner of the schema.
And it indeed did!
Refrence:
https://docs.oracle.com/database/121/DBSEG/dr_ir.htm#DBSEG658
https://docs.oracle.com/cd/B28359_01/appdev.111/b28370/create_package.htm#LNPLS01371
https://docs.oracle.com/cd/B28359_01/appdev.111/b28370/subprograms.htm#LNPLS00809
I know that drop an object can cause to destroy a grant.
But what else can cause to lose a grant over an object?
Am asking that since I have to write some guidelines for the revs DB at work, I'd like to creae a list of operation where is necessary to also regenerate the grants for other schemas.
If also the user that grant access revoked access
you can look at this Question for more info :
Revoke Privileges in Oracle
I want to import schema to my new host. First I had created new user account:
CREATE USER test IDENTIFIED BY test;
What kind of privileges I need to grant to have super role?
(create schema, tables, packages, triggers...etc)
It's one privilege to grant me access to all of them?
You should grant only those privileges that are required for a newly created user to work. One by one.
CREATE SESSION is the first one; without it, user can't even connect to the database.
CREATE TABLE is most probably also required, if user TEST is going to create his own tables.
That's enough to get it started. Once it appears that user needs to create a procedure, you'll grant CREATE PROCEDURE. And so forth.
There are/were roles named CONNECT and RESOURCE which contained the "most frequent" privileges one needed, but their use is - as far as I can tell & in my opinion - discouraged.
I am trying to get over with DBMS_PROFILER, but I face a problem, that I can't get through.
I followed the tutorial on this page:
http://www.oracleflash.com/44/Write-fast-and-efficient-PLSQL---DBMS_PROFILER.html
and everything was fine till I did not change the user. When I run the profiler as the owner of the code, all the statistics are fine, but when I run those procedures as a different user (that of course has EXECUTE permissions) I can see only "ANONYMOUS" in profiler tables.
I found something looking around in the internet, and performed these actions:
I granted execute permissions for user calling procedures,
I also granted DEBUG permissions,
I compiled procedures for DEBUG,
I have checked that code is "INTERPRETED" and not "NATIVE",
finally, calling user also have CREATE PROCEDURE privilege.
Nevertheless, it still doesn't work. The problem is I want to profile application, that is running code as a different user, so I cannot change that. Any ideas what should I do, and why it is not working?
Problem solved. The doc says (in security section) that you need to have privileges to create objects that you want to monitor. I wanted to monitor package in other schemas, so at first I thought I need CREATE PROCEDURE privilege which didn't help. In fact, you need to have privileges to create specifically object you want to monitor, so you simply need to have CREATE ANY PROCEDURE for user from which you are running other shema packages.
You have tagged this question as Oracle 11g, in which case you are in luck. Oracle added a new profiler package, DBMS_HPROF. This is a hierarchical profiler, which means it can drill down into different schemas. Find out more.
I have to install an application server that requires an user to write to the database, possibly create new schemes and such. However, I've always used the "work around" to assign the DBA Role to that user.
I have some questions, as I am not that deep into Oracle security.
Has the DBA role a level of privileges that can affect the whole Oracle installation?
Where can I find what privileges the DBA role exactly have?
How do I create an alternative role?
Thanks,
1) Yes, the dba role should have enough privileges to screw up a database beyond fixing.
2)
select *
from role_sys_privs
where grantee = 'DBA';
3) Unless you plan on having several user with similar privileges, I recommend creating a user and grant all needed privileges explicitly to this user instead of via a role.
You can read more about the topic in
Oracle Database Security Guide chapter 11, Administering User Privileges, Roles, and Profiles
First look into Ronnis' solution. If this is not sufficient create a package, owned by SYSTEM, and grant EXECUTE to the user or users that need it. Add procedures that perform the needed operations taking care to limit their power as much as possible.