Oracle 19c Security Guide 8.2
"The user of a procedure who is not its owner is called the invoker."
Oracle 19c Security Guide 8.3
"When the invoker runs an invoker's rights procedure, this user temporarily has all of the privileges of the invoker."
Isn't this last statement 8.3 trivially true (like a tautology) when applying the definition of invoker from 8.2? The invoker is "this user", so of course "this user" has the privileges of the invoker because they are one and the same. Furthermore, I do not understand what is temporary about it. The fact that this sentence is in the documentation, has an emphasis on the word "all", and specifically mentions temporary behaviour makes me think I'm totally missing the point of what the docs are trying to tell me.
Or, is this a documentation error and it meant to say,
"When the invoker runs an invoker's rights procedure, this procedure temporarily has all of the privileges of the invoker."
Thanks in advance.
Related
When we connect to Oracle database for the first time from SQLPlus command line tool, why do we always connect like this
"sys as sysdba"
Can some one tell me the significance of this?
Why do not we do this in MYSQL?
I am new to Oracle, and this question might sound silly. I am learning using Oracle 11g XE.
SYS and SYSTEM are administrative users, they kind of "own" the database. Data dictionary is stored in SYS schema so - if you screw it up, you'll most probably destroy the database. Therefore, never mess up with it - use it only for necessary administrative tasks. Never touch any SYS owned tables (thinking "if I change this I'll make that happen). Even better, create your own user and grant it DBA privilege - it'll be able to do mostly everything you'd ever want.
SYSDBA is a privilege which is automatically granted to user SYS; it lets it perform high-level administrative tasks (such as backup and recovery or upgrade the database). SYSTEM doesn't have it; that's why you don't specify as sysdba when connecting as SYSTEM.
Furthermore, SYSDBA privilege lets you to connect to database instance although database isn't open yet - and lets you start it up.
Saying that you "always connect as sys as sysdba" - well, you don't have to do that "always". There are other predefined users (such as Scott or HR (Human Resources)) you can use. Default username/password combinations are "scott/tiger" and "hr/hr". Though, they are most probably locked so you can't establish connection. That's why you connect as SYS, unlock those accounts (or create new one(s), depending on what you want to do), and then connect as some other user.
More info here:
SYS and SYSTEM users
SYSDBA and SYSOPER system privileges
Why you don't have that in MySQL? Probably because MySQL isn't Oracle.
Finally, as you're new with Oracle, I'd suggest you to visit & bookmark this page: Oracle Database 10gR2 documentation. Yes, it is kind of "old" and you don't use that version, but it is the last one that separated "Getting Started" and "Most popular" books which makes it easy to find and read. I'd suggest you to read:
Concepts, to learn what Oracle is and how it works
Then, depending on what you'd want to do/be (developer or DBA), pick e.g.
2 day DBA
Administrator's guide
or
SQL reference
PL/SQL user's guide and reference
Application developer's guide - fundamentals
Certainly, you can find these books for database version you do use (11g), it is here: Oracle database online documentation 11g Release 2 (11.2) but - as I said - it is not as nicely presented as 10g.
Good luck with Oracle, enjoy!
Getting ORA-00990: missing or invalid privilege while running the below query on Oracle 11g r2 :
grant inherit any privileges to dbuser1;
Any suggestions on this.
Suggestion is to upgrade to at least 12c to use it. It doesn't exist in 11g, as far as I can tell.
This privilege is first documented in Oracle 12.1
INHERIT PRIVILEGES and INHERIT ANY PRIVILEGES Privileges
Before Oracle Database 12c, an IR unit always ran with the privileges of its invoker. If its invoker had higher privileges than its owner, then the IR unit might perform operations unintended by, or forbidden to, its owner.
As of Oracle Database 12c, an IR unit can run with the privileges of its invoker only if its owner has either the INHERIT PRIVILEGES privilege on the invoker or the INHERIT ANY PRIVILEGES privilege.
I have already tried and tested using UTL_HTTP package to request http using oracle pl/sql but due to some requirement issues I am not allowed to use this package in my work, so I am looking for an alternative of this package in oracle pl/sql to request http.
There is no need for an alternate to UTL_HTTP, that package is only unavailable because of a misunderstanding of the security rules. Ask your DBA to grant execute on UTL_HTTP to public, a role, or your account.
It's important to know where the security rules came from, to know when they no longer apply. Most DBAs have no idea where their security policies originate from. Most of them simply get the scripts or policies from a coworker and don't question it. If you were to trace it back, it's likely that someone at your organization received a script from a security auditor. The security auditors almost always copy their script verbatim from the Security Technical Implementation Guide (STIG), produced by the Department of Defense.
Which means the real security policies can be found in either the 11g Oracle STIG or the 12c Oracle STIG.
The XML file for the 11g guide contains this rule: SV-68213r1_rule, "Execute permission must be revoked from PUBLIC for restricted Oracle packages." That rule recommends executing this command:
revoke execute on UTL_HTTP from PUBLIC;
But the guide clearly says that it is OK to grant execute privileges to specific users. The rule is only to revoke the grant from PUBLIC, not to prevent everyone from using the package. And that rule does not even exist in 12c.
I'm just getting started with Oracle data export and import and things worked perfectly fine the first time around. But then I came back next day repeated the exact same steps on the same systems, but get ORA-01435: user does not exist error.
System Specs for all machines:
-OS: Windows 2012 R2 x64
-Oracle Server: Oracle 11G Express x64
Objective:
I'm exporting data from Oracle server 1 and importing to Oracle server 2.
Procedure:
Export data dump is successful from Oracle server 1.
but when importing the data dump on Oracle server 2, I follow this procedure:
-Stop IIS service
net stop WAS
Create Schema/user account and Grant privileges before import
net stop WAS
sqlplus / as sysdba;
CREATE user PIE1 identified by PASS1;
GRANT ALL PRIVILEGES TO PIE1;
GRANT IMP_FULL_DATABASE TO PIE1;
According to oracle, all goes well, but look at the first image bellow. In DBeaver, I can see that only the User account PIE1 has been created, but NO schema.
Oracle issue 1. User account created, but not the Schema
Question 1: According to Oracle, the command "Create User" IS supposed to also create an associated Schema. Anyone have an idea why this is no longer working for me? It worked once the night before.
I then continue the import procedure as follows:
imp PIE1/PASS1#xe file=c:\Backups\AVUSER2_6_7.dmp log=c:\Backups\import.log fromuser=AVUSER2_6_7 touser=PIE1;
But get the following error:
Oracle claims the User doesn't exist even though it does
Oracle claims the User doesn't exist even though it does. I repeated the entire procedure and even created an identical import/export user account and credentials, and this error still comes up.
Question 2: Any idea why Oracle "Can't find" a user account that's clearly in the database?
Additional Info:
Checked that my windows account is in admin group
Checked that my windows account is in ORA_DBA group
Opened all CMD prompt as Admin
As you implied, users and schemas as the same in Oracle, you can't have a user without a schema. No idea about DBeaver, but as there are other users that aren't listed under 'schemas' (according to your second image - ANONYMOUS, DIP, ...) that seems to be unrelated.
(Purely a guess, but perhaps the user you're connect as in DBeaver just doesn't have visibility of any objects owned by those users - maybe it only lists users it can see in all_objects, say. Pure speculation, but you could investigate that by looking at the data dictionary while connect through SQL*Plus as the same user. According to this old forum post, there is an option to hide empty schemas...)
The import is connecting successfully as PIE1 - you'd get a different error, ORA-01017, if it wasn't and you wouldn't see the 'Connected to...' banner or anything after that.
Your import command has a trailing semicolon that should not be there. The "importing ... objects into" message shows that it's trying to import into the PIE1; user and not the one you actually created, PIE1. Remove that semicolon and try again.
Incidentally, you can probably also remove the #xe TNS alias and stick to a local connection, assuming the environment is configured as it was whenyou ran SQL*Plus. You should also consider using datapump expdp/impdp rather than the legacy exp/imp.
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.