Rocky8 버전 vmware를 추가하여 같이 사용하기로 함
Set-GID 권한
=> 설정된 경우, Egid가 소유그룹의 gid로 저장된다. 해당 디렉터리내 파일을 생성하면 그룹의 gid 권한으로 생성된다.
=> 미설정된 경우, Egid가 접근한 사용자의 gid로 저장된다. 디렉터리내 파일을 생성하면 사용자의 gid로 생성된다.
( 복습
alias -> 내부명령어(/usr/bin/bash) -> 외부명령어(PATH) 순으로 실행됨 )
=> wall명령어의 경로 보여주기 / 경로의 파일을 ll 형식으로 보여주기
=> ll의 항목중 사용자는 /etc/passwd에서, 그룹명은 /etc/group에서 가져와 보여준다
=> rocky8에는 wall 폴더에 set-gid가 설정되어 있지 않다.
wall 명령어 : 현재 접속한 모든 터미널의 유저에게 브로드캐스트 할 수 있다.
wall 명령어로 일반유저가 다른 유저들에게 브로드캐스트 메시지를 보내려면
1. other 권한에 실행 권한 x가 있어야 하고
2. group 권한에 set-gid 권한이 설정되어 있어야 한다
3. 해당 유저의 /dev/pts/유저의번호 디렉터리에 그룹(tty) w 권한이 있어야 한다
일반유저 linuxadmin에서 wall 명령어를 그냥 사용 했을 때
=> 오류는 나지 않지만, 다른 유저에게 메시지가 브로드캐스트 되지 않는다.
실습을 위해
chgrp tty /usr/bin/wall; chmod 2755 /usr/bin/wall
rocky8 wall 폴더에 set-gid를 설정하고
일반유저 linuxadmin에서 wall 명령어를 사용 했을 때
=> root 터미널에도 브로드캐스트된다
=> mesg n 으로 설정하면 브로드캐스트를 받지 않을 수 있다
mesg y => /dev/pts/0의 권한이 crw--w----.
mesg n => /dev/pts/0의 권한이 crw-------.
mkdir -m 2770 /tmp/test // 폴더를 만들고 권한설정
chmod g+s /tmp/test // set-gid 설정
groupadd project // project 그룹을 만들고
chgrp project /tmp/test // project 그룹 소유로 변경
usermod -G wheel,project linuxadmin // linuxadmin의 그룹권한에 project를 추가
ls -ld /tmp/test
drwxrws---. 2 root project 6 4월 20 15:13 /tmp/test
=> cd /tmp/test 하면 linuxadmin도 내부로 접근할 수 있다 ( others에 권한이 없어도, 소유그룹에 속해있으므로 )
touch bb.txt
-rw-rw-r--. 1 linuxadmin project 0 4월 20 15:23 bb.txt
=> set-gid가 설정되어 있으므로 소유그룹이 project로 생성되는 것 확인 ( root, 일반유저 동일 )
( 단, root는 권한이 없어도 rw 권한에 제한받지 않는다 )
gcc -Wall -o /tmp/setgidTest setgidTest.c
=> c파일의 실행파일을 /tmp에 setgidTest 라는 이름으로 생성 (-o), -Wall은 모든 경고문을 출력한다는 뜻
=> set-gid가 설정되면, 프로세스의 실행ID ( = egid )가 소유그룹으로 변경됨을 확인할 수 있다.
sticky bit 권한
=> t (rwx => rwt)로 표기되며, 적용되면 파일을 생성한 소유자만 내용을 수정, 삭제할 수 있다.
=> 이 권한은 디렉터리에만 적용된다.
( sticky bit 권한이 있어도 디렉터리의 w 권한이 없으면 파일을 생성/삭제할 수 없음 )
w
현재 시스템에 로그인한 사용자들 리스트를 보여준다
( 실습 id는 root, user1, linuxadmin으로 총 3개의 id를 사용 )
drwxrwxrwx. 8 root root 183 4월 20 16:08 /tmp
=> sticky bit를 해제했을 때, linuxadmin이 생성한 txt 파일을 user1이 삭제할 수 있다.
drwxrwxrwt. 8 root root 183 4월 20 16:08 /tmp
=> sticky bit를 설정했을 때, user1이 생성한 파일을 linuxadmin이 삭제할 수 없다
마찬가지로 linuxadmin도 user1이 생성한 파일을 삭제할 수 없다
user1이 만든 txt 파일을 linuxadmin이 수정할 수 없고
반대로 linuxadmin이 만든 txt 파일을 user1이 수정할 수도 없다
(단, root는 sticky bit에 영향받지 않는다)
chown : 파일의 소유자를 변경하는 명령어
chgrp : 파일의 소유그룹을 변경하는 명령어
-- 권한 파트 끝 --
리눅스 라이브러리
참고 : https://wiki.kldp.org/HOWTO/html/Program-Library-HOWTO/index.html
C 프로그램의 컴파일과 디컴파일 과정
전처리기 gcc -E → gcc -S(컴파일러cc1) → gcc -c(어셈블러as) → gcc -o(링커ld)
program.c → program.i → program.s → program.o → program
라이브러리 종류
정적static 라이브러리 : ~.a / ~.lib
공유shared 라이브러리 : ~.so / ~.dll
동적 적재dynamically loaded 라이브러리 : ~.so / ~.dll
리눅스 라이브러리 디렉터리
x86 아키텍쳐 : /lib, /usr/lib, /usr/local/lib
x86_64 아키텍쳐 : /lib64, /usr/lib64, /usr/local/lib64
리눅스의 컴파일 방법
1. 동적 링킹 : 필요한 라이브러리를 실행파일과 분리하는 방식.
2. 정적 링킹 : 필요한 라이브러리를 실행파일에 포함시키는 방식.
동적 링크를 사용하면 실행파일에서 사용하는 라이브러리 정보만 포함되고, 실제 라이브러리는 시스템의 라이브러리 경로에 있다. 실행파일이 실행될 때 시스템에서 동적으로 로드되어 메모리에 적재된다.
동적 링크를 사용하는 이유
메모리 공간 절약, 업데이트 용이성, 실행 파일 크기 감소, 라이브러리를 일관되게 업데이트 할 수 있어 보안적 측면에서 용이
yum -y install gcc make gdb glibc.i686 glibc-static glibc-static.i686 \
glibc-devel.i686 libgcc.i686 libstdc++.i686 glibc glibc-devel libgcc libstdc++ ctags vim
=> vim 설치. ( centos7 기준 )
dnf -y install gcc make gdb glibc.i686 --enablerepo=powertools install glibc-static glibc-static.i686 libstdc++-static libstdc++-static.i686 \
glibc-devel.i686 libgcc.i686 libstdc++.i686 glibc glibc-devel libgcc libstdc++ ctags vim
=> vim 설치. rocky linux에는 glibc-static가 powertools 안에 있어서 변경
vim 환경설정에서 달라진 점
=> rocky8 에서는 vim에 붙여넣기 할 때 :set noai :set paste 해주지 않아도 된다
( centos7 에서는 설정해주지 않으면 깨짐 )
gcc -o myprogram myprogram.c
file myprogram
myprogram: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=c3d92006823856c544169d26c8cf5c1baee62095, not stripped
=> file 명령어로 파일 정보 출력. 64비트로 컴파일 되었다는 것을 알 수 있다.
gcc -o myprogram_32 myprogram.c -m32
file myprogram_32
myprogram_32: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=5a69f8f9865ade826dbf39e33ace10e25d1cec90, not stripped
=> 32비트로 컴파일됨
# ldd myprogram
linux-vdso.so.1 (0x00007ffc2a5c4000) ←맨 앞의 0x 제외하고 16자리 * 4 = 64
libc.so.6 => /lib64/libc.so.6 (0x00007f0a3a2c4000)
/lib64/ld-linux-x86-64.so.2 (0x00007f0a3a689000)
# ldd myprogram_32
linux-gate.so.1 (0xf7ee9000) ←맨 앞의 0x 제외하고 8자리 * 4 = 32
libc.so.6 => /lib/libc.so.6 (0xf7d35000)
/lib/ld-linux.so.2 (0xf7eeb000)
=> ldd 명령어는 실행파일이 어떤 라이브러리와 의존관계가 있는지 보여준다
=> 64비트와 32비트는 메모리 주소 공간 크기가 다르다
gcc -static myprogram.c -o myprogram3
gcc -static -m32 myprogram.c -o myprogram3
=> -o 옵션이 가운데 있을 때는 c파일명 실행파일명 순
gcc -o myprogram_t myprogram.c
gcc -o myprogram_t myprogram.c -static
gcc -o myprogram_t myprogram.c -static -m32
=> -o 옵션이 앞에 있을때는 실행파일명 c파일명 순
ll
-rwxr-xr-x. 1 root root 18040 4월 20 17:12 myprogram1
-rwxr-xr-x. 1 root root 16332 4월 20 17:15 myprogram2
-rwxr-xr-x. 1 root root 1708104 4월 20 17:27 myprogram3
-rwxr-xr-x. 1 root root 1456312 4월 20 17:28 myprogram4
=> 정적static 옵션을 사용해 컴파일한 경우 파일 크기가 커진 것을 확인할 수 있다.
※ 라이브러리 관련 중요 파일 삭제해보기
ll /lib64/libc.so.6
lrwxrwxrwx. 1 root root 12 2월 21 03:00 /lib64/libc.so.6 -> libc-2.28.so
=> glibc의 일부로 리눅스 시스템에서 C 프로그램 실행시 필요한 기본적인 기능과 함수들을 제공하는 파일
이 파일이 삭제되면 외부 명령어들이 실행되지 않고
리눅스를 재부팅해도 부팅되지 않는다
Troubleshooting > Rescue a Rocky Linux system
기다리면
1번 입력
엔터를 치면 sh-4.4# 쉘이 떨어지고
cp /usr/lib64/libc-2.28.so /mnt/sysroot/usr/lib64
reboot
다시 CMOS에서 Hard-Drive를 위로 올린 후 실행하면 자동으로 재시작된다.
이 때 부팅하면 정상적으로 실행된다.
