I want to know what is the difference between the following two statements in oracle:
GRANT DBA TO Jack
GRANT ALL PRIVILEGES TO Jack
I advise you not to try providing dba and NEVER provide ALL PRIVILEDGES to any user, because such thing should be done only by experienced developers.
Usually there is only ONE user who is provided DBA role.
As per oracle documentation:
When oracle database is installed, there are two admin roles created:
1. SYS 2. SYSTEM
An SYS role can access internal data dictionary tables of oracle database.
All of the base tables and views for the database data dictionary are stored in the schema SYS. These base tables and views are critical for the operation of Oracle Database. To maintain the integrity of the data dictionary, tables in the SYS schema are manipulated only by the database.
If you flirted with any internal sys tables, you may face license cancellation
The SYSTEM username is used to create additional tables and views that display administrative information, and internal tables and views used by various Oracle Database options and tools. Never use the SYSTEM schema to store tables of interest to non-administrative users.
The DBA role does not include the SYSDBA or SYSOPER system privileges. These are special administrative privileges that allow an administrator to perform basic database administration tasks, such as creating the database and instance startup and shutdown.
Here GRANT ALL PRIVILEGES are provided to user on particular object, even system object, and this does not includes sys and system privilege, you can do any action on such object, this is why you should avoid using ALL PRIVILEGES.
Related
I'm new to Oracle and I'm currently hardening a database.
It's a good idea to drop SYS and SYSTEM users? normally default accounts are dropped because of security reasons, I can do that on Oracle, or I will break something?
From the documentation (emphasis added):
All databases include the administrative accounts SYS, SYSTEM, and DBSNMP. Administrative accounts are highly privileged accounts, and are needed only by individuals authorized to perform administrative tasks such as starting and stopping the database, managing database memory and storage, creating and managing database users, and so on. You log in to Oracle Enterprise Manager Database Express (EM Express) with SYS or SYSTEM. You assign the passwords for these accounts when you create the database with Oracle Database Configuration Assistant (DBCA). You must not delete or rename these accounts.
And:
All base (underlying) tables and views for the database data dictionary are stored in the SYS schema. These base tables and views are critical for the operation of Oracle Database.
So no, it is not a good idea, and it would destroy your database.
normally default accounts are dropped because of security reasons, I can do that on Oracle, or I will break something?
The first documentation link above also says (emphasis added again):
All databases also include internal accounts, which are automatically created so that individual Oracle Database features or components such as Oracle Application Express can have their own schemas. To protect these accounts from unauthorized access, they are initially locked and their passwords are expired. (A locked account is an account for which login is disabled.) You must not delete internal accounts, and you must not use them to log in to the database.
And it mentions sample schema accounts, which you can choose not to install in the first place, but which could be dropped if required.
The main thing is to secure all accounts, and you should limit any accounts you create to only have the minimum privileges necessary.
You can also read more about this in the database administrator's guide,
It is a very bad idea. I don't think the database will even work without them and doubt that the drop is allowed. Make sure the accounts are safe instead.
I can't grant select on some tables (say SYS.AQ$SCHEDULER_EVENT_QTAB).
However, I can see these tables in dba_objects.
I've an absolutely free autonomous database on Oracle cloud.
What should I do?
The ADMIN user does not have privileges to grant access to SYS objects in an Autonomous Database. Because of the shared nature of autonomous database services, full access to the SYS schema is not possible. If access to the tables or views in question cannot be obtained from an existing pre-defined role, then you will not be able to access them directly. From the documentation:
Because Oracle Autonomous Database imposes security controls and
performs administrative database tasks for you, the ADMIN user does
not have as many privileges as the SYS user. Here is a list of the
privileges that the ADMIN user does not have but that the SYS user in
an Oracle Database does have:
ALTER LOCKDOWN PROFILE
BACKUP ANY TABLE
BECOME USER
CREATE ANY JOB
CREATE ANY LIBRARY
CREATE LIBRARY
CREATE LOCKDOWN PROFILE
CREATE PLUGGABLE DATABASE
DEQUEUE ANY QUEUE
DROP LOCKDOWN PROFILE
EM EXPRESS CONNECT
ENQUEUE ANY QUEUE
EXPORT FULL DATABASE
FLASHBACK ANY TABLE
FLASHBACK ARCHIVE ADMINISTER
GRANT ANY PRIVILEGE
GRANT ANY ROLE
IMPORT FULL DATABASE
INHERIT ANY PRIVILEGES
LOGMINING
MANAGE ANY FILE GROUP
MANAGE ANY QUEUE
MANAGE FILE GROUP
USE ANY JOB RESOURCE
USE ANY SQL TRANSLATION PROFILE
I'm using Oracle's 10g version.
In the database, I would like to create a configuration table and fill it with data.
Then the other users can not change anything in it, and even better that it was not at all visible to other users. Is it possible to somehow hide the table?
Regards
Create a separate schema for that table. Create a package that provides an API to your configuration data (e.g. to get a value that is needed by another program).
Revoke CREATE SESSION privilege from that schema (i.e. just don't grant any privileges to the schema at all). Don't grant any privileges on the table. The only users who will be able to see the table are those with DBA privileges.
The only thing that database sessions will be able to do is execute the package, IF they have been granted EXECUTE privilege on it.
If you do not grant enough privileges to other users, they could not see your objects.
I have access on tables but when I run the same query in Anonymous block it fails with
ORA-00942: table or view does not exist
The Oracle security model means that we cannot build database objects (views, stored procedures, etc) using privileges granted to our account through a role. The privileges have to be explicitly granted to our named account.
This applies to anonymous blocks as well.
So, if you want to build PL/SQL which runs against database objects in other schemas you will have to ask the schema owner - or the DBA - to grant you the privileges you need.
What are the differences between the Oracle SYS and SYSTEM built in accounts?
Edit: Apart from 3 letters!
SYS owns the oracle data dictionary. Every object in the database (tables, views, packages, procedures, etc. ) all have a single owner. For the database dictionary, and a whole lot of special tables (performance views and the like) are all owned by the SYS user.
The SYSTEM user is supposed to be the master DBA user, with access to all of these object. This reflects an early, and long time, Oracle security design philosophy. You build the application using one user, then create a second with access (select, update, delete) but not drop privileges. This gives you a "super-user" access to your schema without being able to destroy it accidentally. Over the years, thing have been added to the SYSTEM account that may have needed to be in the SYS account. But very few people want to give out access to their SYS account if they don't have to.
SYS can connect AS SYSDBA, SYSTEM cannot.
SYSDBA privilege is required to perform certain administrative tasks, like CREATE DATABASEand DROP DATABASE, and query any tables despite GRANT'ed permissions on them.
In fact, whenever you connect as SYSDBA, you become a SYS.