OS 사용자와 소유권

Oracle 설치용 그룹과 oracle 계정 만들기, UID, GID 고정 이유, 설치 디렉터리 소유권, chown의 소유자, 그룹, 재귀 변경과 sudo 허용

useraddgroupaddchownidgetentsudoersoinstall

#핵심 요약

Oracle 설치 전에 oinstall(기본 그룹), dba, asmadmin 같은 그룹과 oracle 계정을 만들고, /u01/app 아래 소유권을 oracle:oinstall로 맞춤

RAC, Data Guard처럼 여러 서버가 같은 파일을 볼 때는 UID, GID가 서버마다 같아야 소유권이 바르게 해석되므로 번호를 직접 지정함

chown 소유자:그룹 대상은 둘 다, chown :그룹 대상이나 chgrp는 그룹만, -R은 하위까지 바꿈

#개념과 동작 원리

항목	의미
기본 그룹 `useradd -g`	계정이 만든 파일에 붙는 그룹, 하나만 지정
보조 그룹 `useradd -G`	추가로 속하는 그룹들, 쉼표로 여러 개
`-u`, `-d`, `-m`, `-s`	UID, 홈 경로, 홈 디렉터리 생성, 로그인 셸
`oinstall`	Oracle 인벤토리 소유 그룹, oracle 계정의 기본 그룹
`dba`	`/ as sysdba` OS 인증에 쓰이는 그룹
`asmadmin`, `backupdba`	ASM 관리, RMAN 백업 권한(SYSBACKUP)용 그룹
`getent passwd·group`	계정, 그룹이 있는지와 번호 확인
`id 계정`	UID, 기본 그룹, 보조 그룹을 한 줄로

#필수 명령어 또는 SQL

#그룹과 계정 확인, 생성

root 셸 (새 서버)조회만 함

getent passwd oracle
getent group oinstall
getent group dba
getent group asmadmin
cut -d: -f3 /etc/group | sort -n

root 셸 (새 서버)객체 또는 설정을 변경함

groupadd -g 54321 oinstall
groupadd -g 54322 dba
groupadd -g 54329 asmadmin
useradd -u 54321 -g oinstall -G dba,asmadmin -d /home/oracle -m -s /bin/bash oracle
passwd oracle
id oracle

결과 해석:

실습 기록: 새 서버에서는 oinstall이 1001, dba가 1002로 이미 있었는데 preinstall 패키지가 만든 것이었음
수업은 이를 지우고 54321, 54322로 다시 만듦

cut -d: -f3 /etc/group | sort -n은 쓰이고 있는 GID를 번호순으로 보여 줘, 비어 있는 번호를 고를 때 씀

기대 결과: uid=54321(oracle) gid=54321(oinstall) groups=54321(oinstall),54322(dba),54329(asmadmin)

비밀번호가 8자보다 짧으면 passwd가 경고하지만 root는 그대로 바꿀 수 있음
운영 서버는 정책에 맞는 비밀번호를 씀

수업 자료의 정리 단계에는 userdel -R oracle로 적힌 곳이 있는데, 홈 디렉터리까지 지우는 옵션은 -r(소문자)임
계정 삭제는 홈과 메일까지 지우므로 운영 계정에는 하지 않음

#설치 디렉터리와 소유권

root 셸객체 또는 설정을 변경함

mkdir -p /u01/app/oracle
mkdir -p /u01/app/oraInventory
chown -R oracle:oinstall /u01/app
chmod -R 775 /u01/app
ls -ld /u01 /u01/app /u01/app/oracle

결과 해석:

기대 결과: /u01은 root root, /u01/app 아래는 oracle oinstall

/u01 자체가 root 소유인 것은 정상이지만 /u01/app 아래가 root 소유면 설치 중 Permission denied가 남

설치 전에 미리 만들 경로 예는 $ORACLE_HOME(/u01/app/oracle/product/19.0.0/dbhome_1), 데이터 파일 경로(/u01/app/oracle/oradata/ORCL), FRA(/u01/app/oracle/fast_recovery_area)임

#chown으로 소유자, 그룹 바꾸기

Linux Bash (bkpown_lab)조회만 함

ls -lR
id

root 셸 (/home/oracle/bkpown_lab)객체 또는 설정을 변경함

chown root:root backupsets/*.bkp
ls -l backupsets
chown oracle:backupdba backupsets/full_20260718_01.bkp
chown :oinstall backupsets/full_20260718_01.bkp
cd /home/oracle
chown -R root:root bkpown_lab/
ls -ld bkpown_lab/
ls -l bkpown_lab/

결과 해석:

실습은 RMAN 백업 조각, 컨트롤 파일 복사본, 감사 파일, spfile 이름의 가짜 파일로 만든 백업 볼륨임

백업 조각이 root 소유가 되는 것은 root로 작업하다 생기는 사고 재현이며, 이후 oracle 계정의 RMAN이 그 파일을 읽거나 지우지 못하게 됨

oracle:backupdba처럼 소유자와 그룹을 한 번에, :oinstall처럼 콜론 앞을 비우면 그룹만 바꿈

실습 기록: chown -R root:root bkpown_lab/ 뒤 audit, backupsets, control, spfileORCL.ora와 bkpown_lab 자체가 모두 root root로 나옴
-R은 디렉터리 안의 모든 항목을 바꾸므로 경로를 다시 확인하고 씀

수업 자료의 chown 문제 상당수는 정답 칸이 비어 있어, 위 그룹만 변경, 한 파일 변경 명령은 문제 설명과 예상 결과에 맞춘 것임

#oracle 계정에 sudo 허용

root 셸객체 또는 설정을 변경함

visudo -f /etc/sudoers.d/oracle_dba
cat /etc/sudoers.d/oracle_dba
su - oracle
sudo date

파일 (/etc/sudoers.d/oracle_dba)객체 또는 설정을 변경함

oracle ALL=(ALL) /bin/date

결과 해석:

visudo -f는 저장 전에 문법을 검사해, 잘못된 sudoers 파일로 sudo 자체가 막히는 사고를 막음

필요한 명령만 적으면 그 명령만 root로 실행되며, oracle ALL=(ALL) ALL은 root 전체 권한을 줌

실습 기록: 처음 sudo date는 oracle 비밀번호를 묻고, 잠시 뒤 다시 실행할 때는 묻지 않음
수업 파일에는 존재하지 않는 경로 /usr/date도 함께 적혀 있음

실습에서는 which date로 실제 경로(/bin/date)를 먼저 확인함

#사용 조건과 주의사항

이미 설치된 서버에서 그룹, 계정을 지우고 다시 만들면 기존 파일의 소유자가 숫자로만 남아 소유권이 깨짐

preinstall 패키지가 만든 계정, 그룹과 손으로 만든 것이 섞이면 id oracle로 최종 결과를 반드시 확인함

chown -R, chmod -R은 /나 /u01처럼 넓은 경로에 실수로 쓰면 되돌리기 어려움