You are on page 1of 25

Database Accounts and Privileges

The Server Configuration  uses two SQL database accounts:


• the Configuration account /user account and
• the Service account.
Both are set up by the database administrator.
Accounts can be added, or changed. Once an account is added, it is
assigned to all services.
Configuration Account
The Configuration Account is used to connect to the database to perform
operations, including creating, upgrading and configuring the Management
Server and database. The account is used to perform the following tasks:
• Create the database - only performed if the database does not exist,
requires dbcreator rights.
• Create logins - only performed if a login does not exist, requires
securityadmin rights.
• Ensure the database schema matches the version defined by the product.
• Check for variances - whether the properties of the database match the
product expectations.
• Confirm the database user logins.
• Populate the initial data set into the database.
The Configuration account must have dba rights, or be a member of the
Management Server Administrator role. Some additional rights may be
needed for optional tasks, which are detailed in the list above.
User Accounts

For users to access your database, you must create user accounts and grant
appropriate database access privileges to those accounts.
A user account is identified by a user name and
defines the attributes of the user, including the following:
• Authentication method
• Password for database authentication
• Default tablespaces for permanent and temporary data storage
• Tablespace quotas
• Account status (locked or unlocked)
• Password status (expired or not)
When you create a user account, you must not only assign a user name,
a password, and default tablespaces for the account, but you must
also :
Grant the appropriate system privileges, (ex: For example,
the privileges to create tablespaces and to delete the rows of any
table in a database)
object privileges (object privileges include SELECT, INSERT, UPDATE,
DELETE, ALTER, INDEX on tables and views and EXECUTE on
procedures, functions, and packages.), and
 roles to the account.
When you create a user account, you are also implicitly creating a schema
for that user. A schema is a logical container for the database objects (such
as tables, views, triggers, and so on) that the user creates. The schema
name is the same as the user name, and can be used to unambiguously
refer to objects owned by the user.
For example, hr.employees refers to the table named employees in
the hr schema. (The employees table is owned by hr.) The terms database
object and schema object are used interchangeably.
When you delete a user, you must either simultaneously delete all
schema objects of that user, or you must have previously deleted the
schema objects in separate operations.
Predefined User Accounts

• accounts SYS, 
• SYSTEM, and
•  DBSNMP
• Etc….
User Privileges and Roles

• User privileges provide a basic level of database security. They are


designed to control user access to data and to limit the kinds of SQL
statements that users can execute.
• When creating a user, you grant privileges to enable the user to
connect to the database, to run queries and make updates, to create
schema objects, and more.
types of user privileges
System privileges
A system privilege gives a user the ability to perform a particular action,
or to perform an action on any schema objects of a particular type.
For example, the system privilege CREATE TABLE permits a user to
create tables in the schema associated with that user, and the system
privilege CREATE USER permits a user to create database users.
Object privileges:

• An object privilege gives a user the ability to perform a particular


action on a specific schema object. Different object privileges are
available for different types of schema objects.

• The privilege to select rows from the EMPLOYEES table or to delete


rows from the DEPARTMENTS table are examples of object privileges.
• Managing privileges is made easier by using roles, which are named
groups of related privileges.
• You create roles, grant system and object privileges to the roles, and
then grant roles to users. You can also grant roles to other roles.
Unlike schema objects, roles are not contained in any schema.
CONNECT Enables a user to connect to the database. Grant this role to any user or application that needs database access.

RESOURCE Enables a user to create, modify, and delete certain types of schema objects in the schema associated with that user.
Grant this role only to developers and to other users that must create schema objects. This role grants a subset of the
create object system privileges. For example, it grants the CREATE TABLE system privilege, but does not grant the CREATE
VIEW system privilege. It grants only the following privileges: CREATE CLUSTER, CREATE INDEXTYPE, CREATE
OPERATOR, CREATE PROCEDURE, CREATE SEQUENCE, CREATE TABLE, CREATE TRIGGER, CREATE TYPE.

DBA Enables a user to perform most administrative functions, including creating users and granting privileges; creating and
granting roles; creating, modifying, and deleting schema objects in any schema; and more. It grants all system privileges,
but does not include the privileges to start or shut down the database instance. It is by default granted to
users SYS and SYSTEM.
As a database administrator (DBA), you can create, modify, and delete
schema objects in your own schema and in any other schema. For
purposes of this discussion, a database administrator is defined as any
user who is granted the DBA role. This includes
the SYS and SYSTEM users by default. Oracle recommends granting
the DBA role only to those users who require administrative type
access.
You can enable other users to manage schema objects without
necessarily granting them DBA privileges.
For example, a common scenario is to enable an application developer
to create, modify, and delete schema objects in his or her own schema.
To do so, you grant the RESOURCE role to the application developer.
How to Create a User and Grant Permissions in Oracle

Once connected as SYSTEM, simply issue the CREATE USER command to


generate a new account.

CREATE USER admin1 IDENTIFIED BY admin321;


• Log in to SQL *Plus:
sqlplus '/ as sysdba'
• Create a new user with an administrator password:
create user admin1 identified by admin321;
• admi1 is the name of the user you are creating and admin321 is the
password that you want to assign to the user.
• Assign the sysdba privilege to the new Oracle user:
grant sysdba to admin1;
The Grant Statement

With our new admin1 account created, we can now begin adding


privileges to the account using the GRANT statement. GRANT is a very
powerful statement with many possible options, but the core
functionality is to manage the privileges of
both users and roles throughout the database.
Typically, you’ll first want to assign privileges to the user through
attaching the account to various roles, starting with the CONNECT role:

GRANT CONNECT TO admin1;


Providing Roles

In some cases to create a more powerful user, you may also consider
adding the RESOURCE role (allowing the user to create named types for
custom schemas) or even the DBA role, which allows the user to not
only create custom named types but alter and destroy them as well.

GRANT CONNECT, RESOURCE, DBA TO admin1;


Assigning Privileges

you’ll want to ensure the user has privileges to actually connect to the
database and create a session using GRANT CREATE SESSION. We’ll also
combine that with all privileges using GRANT ANY PRIVILEGES.

GRANT CREATE SESSION GRANT ANY PRIVILEGE TO admin1;


We also need to ensure our new user has disk space allocated in the
system to actually create or modify tables and data, so we’ll GRANT
TABLESPACE like so:
GRANT UNLIMITED TABLESPACE TO admin1;
Table Privileges

While not typically necessary in newer versions of Oracle, some older installations may require
that you manually specify the access rights the new user has to a specific schema and database
tables.
For example, if we want our admin1 user to have the ability to perform SELECT, UPDATE, INSERT,
and DELETE capabilities on the books table, we might execute the following GRANT statement:
GRANT
SELECT,
INSERT,
UPDATE,
DELETE
ON
hr.hire_verify(this is a view)
TO
admin1;
These properties of roles allow for easier privilege management
within a database:

• Reduced privilege administration Rather than explicitly granting the


same set of privileges to several users, you can grant the privileges for
a group of related users to a role, and then only the role needs to be
granted to each member of the group.
• Dynamic privilege management If the privileges of a group must
change, only the privileges of the role need to be modified. The
security domains of all users granted the group's role automatically
reflect the changes made to the role.
• Selective availability of privileges You can selectively enable or disable
the roles granted to a user. This allows specific control of a user's
privileges in any given situation.
• Application awareness Because the data dictionary records which roles
exist, you can design database applications to query the dictionary and
automatically enable (and disable) selective roles when a user attempts
to execute the application via a given username.
• Application-specific security You can protect role use with a password.
Applications can be created specifically to enable a role when supplied
the correct password. Users cannot enable the role if they do not know
the password.
REVOKE STETAMENT
The Oracle REVOKE statement revokes system and object privileges
from a user. Here is the basic syntax of the Oracle REVOKE statement:
REVOKE {system_privilege | object_privilege } FROM user;
In this syntax:
First, specify the system or object privileges that you want to revoke
from the user.
Second, specify the user from which you want to revoke the
privileges.

You might also like