[linux] 소유자, 그룹, 권한을 잘 생각해야 한다. (원인 미파악)

SSL 인증서 및 도메인 교체 중  nginx 리로드, 리스타트 후 206, 404 가 발생하고, 나중에는 접속이 되지 않는 현상이 발생하였다. 여러 사람이 조치를 취하면서 더 꼬이게 된 것인지, 이러한 현상의 정확한 원인이 무엇이었는지 파악해보고자 한다.
무언가 문제가 발생했을 때 침착하게 현 상황을 분석하고 섣불리 다른 조치를 취하지 않는 것이 좋다는 것을 깨달았다. 절차대로 조작하고 이것저것 건드려서 일을 키우지 않고 정확한 원인을 파악하는 것이 중요하다.

1. nginx listen 포트를 사용하지 않는 port로 설정하였다. firewalld에서 443을 8443으로 포워딩하고 있었는데 이를 파악하지 않고 listen 포트를 443으로 설정하였다.
2. 각 도메인의 ssl 인증파일이 다르기 때문에 도메인 별 server블록을 설정하고 리슨포트는 모두 8443으로 통일하였다.  웹사이트 접속은 가능하였으나 페이지가 제대로 로드되지 않고 206 에러가 발생하였다.
3. nginx 컨피그 파일의 문제로 판단하고 컨피그 파일 원복 및 nginx 리로드를 하였으나 웹사이트가 로드되지 않았다.
4. 3번까지의 작업은 일반 사용자A로  로그인하여 sudo 권한으로 수행하였다.
5. 다른 직원이 nginx 및 tomcat을 재실행하였다.
6. 관련 캐시와 로그 파일을 삭제하고 캐시 및 로그 파일 저장 디렉터리의 소유자를 일반사용자 A로 변경하였다.
7. kill 명령어로 nginx 및 톰캣 프로세스를 모두 종료하였다.

8. 일반사용자 A로 톰캣과 nginx를 실행하였다.
결과적으로는 위의 방법으로 해결이 되었는데 이러한 문제가 발생한 원인과 조치의 키포인트가 이해되지 않아 조사 및 테스트를 해보았다. nginx의 권한이 변경되면서 log 및 cache에 제대로 접근하지 못해 발생한 문제로 추정하고 접근하였다.

which nginx : nginx를 실행시키기 위해 경로를 확인하였다.
who : 현재 유저를 확인하였다. whoami를 써야 정확히 현재 내 ID를 확인할 수 있다. who를 쓰면 접속한 모든 유저가 나온다.
ps -ef | grep nginx :  nginx 프로세스가 root권한으로 실행되고 있음을 확인한다.
To see every process on the system using standard syntax:
          ps -e
          ps -ef
          ps -eF
          ps -ely

su testUser, whoami

testUser로 유저를 변경하고 whoami로 확인한다.

cat /etc/group

testUser는 wheel그룹에 소속되어 있기 때문에 sudo 명령어로 root 권한을 얻어 명령어를 사용할 수 있다.

/usr/sbin 의 nginx 실행 파일의 소유자, 그룹, 권한을 확인한다.

/usr/sbin/ 경로내 nginx 실행파일의 소유자 및 그룹은 root, 권한(퍼미션)은
rwxr-xr-x로 다음과 같다. (소그기(소유자/그룹/기타 사용자))
소유자: 읽기, 쓰기, 실행 가능
그룹: 읽기, 실행 가능
기타 사용자: 읽기, 실행 가능

기타 사용자도 sudo권한 없이 실행은 할 수가 있는 상태이다. 이 상태에서 테스트해볼 것은 다음 표와 같다. 테스트의 목적은 root로 실행 중인 ngin를 일반사용자가 리로드, 리스타트, 스톱 후 실행 등의 조작을 했을 때 nginx 프로세스 실행자가 변하는지 여부이다.
결과적으로 일반사용자가 sudo명령어 없이는 nginx의 reload 및 재부팅이 불가하였고, sudo명령어를 사용한 경우에도 nginx의 실행자가 일반사용자로 변경되지는 않았다.

명령어 \ sudo 사용 여부	sudo 명령어 이용	sudo 명령어 미이용
nginx reload	3번 케이스	1번 케이스
nginx stop & start	4번 케이스	2번 케이스

 
1번 케이스 - sudo 없이 reload

기존 nginx 실행자는 root, 일반사용자가 sudo 없이 reload 수행

nginx: [alert] could not open error log file: open() "/var/log/nginx/error.log" failed (13: Permission denied) 2023/06/30 13:21:27 [warn] 27991#27991: the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:2 2023/06/30 13:21:27 [notice] 27991#27991: signal process started 2023/06/30 13:21:27 [alert] 27991#27991: kill(21491, 1) failed (1: Operation not permitted)

 
2번 케이스 - sudo 없이 stop

nginx: [alert] could not open error log file: open() "/var/log/nginx/error.log" failed (13: Permission denied) 2023/06/30 13:23:49 [warn] 28967#28967: the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:2 2023/06/30 13:23:49 [notice] 28967#28967: signal process started 2023/06/30 13:23:49 [alert] 28967#28967: kill(21491, 15) failed (1: Operation not permitted)

sudo명령어를 사용하지 않는 경우 error.log 권한 거부로 불가하다. 해당 경로의 퍼미션을 확인해 보았다.

/var/log/nginx

access.log, error.log , nginx.pid 세 개 파일은 일반사용자의 권한이 제한되어 있다. 일반사용자가 nginx 실행파일의 실행권한이 있더라도 error 및 log파일에 접근이 불가한 것이다.
*nginx.pid 파일 알아보기)

nginx.pid 파일은 Nginx 서버 프로세스의 PID(Process ID)를 저장하는 파일입니다. PID는 실행 중인 프로세스를 고유하게 식별하는 번호입니다. nginx.pid 파일은 Nginx 서버가 시작될 때 자동으로 생성되고, Nginx 마스터 프로세스가 자신의 PID를 해당 파일에 기록합니다. 이렇게 함으로써 운영 체제나 관리 도구는 Nginx 서버 프로세스를 제어하거나 모니터링할 수 있습니다. 일반적으로 nginx.pid 파일은 /var/run/nginx.pid 또는 /run/nginx.pid와 같은 경로에 위치합니다. 그러나 이 경로는 운영 체제나 Nginx 구성에 따라 다를 수 있습니다. nginx.pid 파일은 다음과 같은 목적을 가지고 있습니다:

프로세스 관리: nginx.pid 파일은 Nginx 프로세스의 PID를 저장하여 프로세스를 관리하는 데 사용됩니다. 이 파일을 통해 운영 체제나 다른 도구가 Nginx 프로세스를 시작, 중지 또는 재시작할 수 있습니다.

상태 모니터링: nginx.pid 파일을 사용하여 Nginx 서버의 상태를 모니터링할 수 있습니다. 예를 들어, 프로세스 모니터링 도구는 이 파일을 통해 Nginx 서버의 실행 여부 및 상태를 확인할 수 있습니다.nginx.pid 파일은 Nginx 서버의 안정적인 운영과 관리에 중요한 역할을 합니다. 따라서 이 파일은 일반적으로 Nginx 서버가 정상적으로 실행 중인지 확인하거나 서버를 관리하는 데 필요한 도구에 의해 사용됩니다.

출처 : chatGPT

3번 케이스 - sudo로 reload

sudo /usr/sbin/nginx -s reload

testUser 로그인 상태에서 sudo 권한으로 reload를 하여도 nginx의 master process와 worker process의 실행자 UID가 변하지 않았다.
4번 케이스 - sudo로 stop 후 실행

sudo /usr/sbin/nginx

실행 전 실행 후 PID는 변화하였으나 실행 UID가 변하지 않았다.
root로 실행되어야 할 nginx가 일반사용자로 실행되면서 관련된 파일에 접근하지 못하여 에러가 발생했다는 전제로 테스트를 진행하였으나 원인을 명확하게 파악하지 못하였다. 한편, 테스트를 진행한 서버와 문제가 발생하였던 서버의 환경이 다르기 때문에, 문제가 발생했던 서버에서는 error.log 에 일반사용자 권한이 있어서 sudo권한 없이 일반사용자가 nginx를 컨트롤할 수 있었을지도 모른다.

chown -R testUser:testUser /var/log/nginx

/var/nginx/log의 파일 소유자와 그룹을 모두 testUser로 변경하였다.
 

sudo 권한없이 일반사용자로 reload 시도. error.log 에러는 피했지만

nginx: [warn] the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:2 nginx: [alert] kill(7715, 1) failed (1: Operation not permitted)

user디렉티브는 마스터 프로세스 상위 권한

nginx.conf 에서 에러가 나는 것으로 보인다.

nginx.conf의 user 이름 설정이 명시용이 아니고 실제로 뭔가 기능을 하고 있었던 것인지 확인이 필요하다. user를 testUser로 변경해 본다.

vi /etc/nginx/nginx.conf

 

nginx.conf 의 user 를 변경하고 sudo 명령어로 reload를 하자 nginx worker process의 실행자 UID가 변경되었다

nginx master프로세스와 worker프로세스에 대해 알아볼 필요가 있다. 마스터 프로세스는 모든 권한을 가지고 있고 워커 프로세스는 nginx.conf 에서 설정한 user의 권한을 갖는 것으로 보인다.
명확하게 답을 얻지는 못했지만 이것저것 적으면서 많이 배운 것 같다. 더 많이 알게 되었을 때 이 문제를 다시 보면 원인이 무엇이었는지 이해하게 될 것으로 생각하고 잠시 보류한다.
 
로그를 확인해보기

nginx error.log

error.log-2023.06.29