Database Reference
In-Depth Information
These are the OS groups available in 12c:
•
OSDBA
members belonging to the “
dba
” group specified in
config.c
can log in using the
“/ as sysdba”, which still has full control over the database. OSDBA is a group specified in
config.c that is intended for DBAs. Members of the group can log in using the “
/ as sysdba
”
syntax and have full control over the database.
•
OSOPER
membership optionally enables members of the OS “
oper
” group to connect to the
database “
as SYSOPER
” to allow starting/stopping and backups without the ability to look at
user data.
•
OSBACKUPDBA
as members of OS “
backupdba
” group can log in using the “as SYSBACKUP”
to allow juniors to perform backup-related tasks.
•
OSDGDBA
as members of OS “
dgdba
” group can log in using the “as SYSDG” to allow juniors
to perform dataguard-related tasks.
•
OSKMDBA
as members of OS “
kmdba
” group can manage the Oracle wallet, which provides an
additional method of access to the database on the basis of a certificate file that is resident on
the OS, and also enables data file encryption.
•
OSASM
as members of the “
asmdbadmin
” group are given the SYSASM privilege for managing
ASM and is sometimes used as the grid infrastructure owner.
•
OSDBA for ASM
as members of the “
asmdba
” OS group have read and write access to files
within ASM. GI and RDBMS owners should be included in this group.
•
OSOPER for ASM
optionally enables connection to ASM from the “
asmoper
” OS group for
junior ASM maintenance similar to the main RDBMS OSOPER.
•
“
oinstall
” OS group owns the Oracle inventory where there is a record of installed software
and patch levels, and should be the primary group for all Oracle-related OS accounts.
•
“
oracle
” is the software-owning account, i.e., Oracle binary (this account should have
OSDBA as primary group and the other groups listed previously as secondary groups;
“
•
root
” is needed for
orainstRoot.sh
and
root.sh
, which in turn call the following scripts and
run them as root. It is worth inspecting these files before running them.
•
rootmacro.sh
•
rootinstall.sh
•
setowner.sh
•
rootadd_rdbms.sh
rootadd_filemap.sh
For instance,
rootadd_rdbms.sh
sets access to the
dbms_scheduler
wallet to 700 Unix permissions. This means
that a DB session accessing the OS from
JAVA_ADMIN, CREATE TABLE, UTL_
FILE, etc. will have full control over the
wallet, thus enabling a DB session to modify or delete that wallet. If the wallet is providing credentials for security
checks then they will no longer occur.
In theory there should be segregation of duty between the above privileges, which should be held by separate
staff. In practice, most DBA team members achieve access through the
"oracle"
account and there is little
segregation of duty. However, even small teams can have a DBA team lead, who may have some root access, and a
junior DBA, who has user management duties. Given that there have been a number of methods to escalate privilege
from system privileges in the database, there has not been much attention paid to the OS accounts and groups.
•
