알짜게시판

아파치 기본 실행 구조와 파일 접근 방식

아파치 웹 서버는 기본적으로 하나의 서비스 계정으로 실행되며, 대부분의 환경에서는 apache, www-data와 같은 전용 계정을 사용한다. 이 구조에서는 모든 HTTP 요청이 동일한 사용자 권한으로 처리되기 때문에, 파일 시스템 접근 역시 해당 계정 기준으로 이루어진다. 즉, 웹 루트 디렉터리나 업로드 경로에 대한 읽기 및 쓰기 권한이 이 계정에 맞춰져 있어야 정상 동작한다.

문제는 일반 사용자 계정이 별도로 존재하는 환경에서 발생한다. 예를 들어 /home/user 경로 아래에 웹 파일을 두고 이를 아파치에서 제공하려는 경우, 기본 설정만으로는 접근이 제한된다. 이는 리눅스 파일 시스템이 사용자, 그룹, 기타 사용자 단위로 권한을 구분하기 때문이다.

현재 구조에서는 아파치 프로세스가 일반 사용자 계정의 권한을 직접 사용할 수 없고, 반대로 일반 사용자도 아파치 계정의 권한을 공유하지 않는다. 이로 인해 파일 업로드, 로그 기록, 캐시 생성과 같은 작업에서 권한 충돌이 발생한다. 이런 상황에서 권한을 단순히 777로 열어두는 방식은 보안상 적절하지 않기 때문에 다른 접근이 필요하다.

권한 공유 방식의 한계와 개선 필요 지점

기존 방식에서 흔히 사용하는 방법은 디렉터리 권한을 완전히 개방하거나, 특정 파일에 대해 개별적으로 권한을 부여하는 것이다. 예를 들어 아래와 같이 설정할 수 있다.

chmod -R 777 /home/user

이 방식은 입력으로 특정 경로를 받아 모든 사용자에게 읽기, 쓰기, 실행 권한을 부여한다. 결과적으로 아파치뿐 아니라 시스템의 모든 사용자 계정이 해당 디렉터리에 접근할 수 있게 된다.

하지만 이 구조는 다음과 같은 한계를 가진다. 첫째, 접근 제어가 불가능해진다. 둘째, 파일 변경 이력을 추적하기 어렵다. 셋째, 예상하지 못한 프로세스가 파일을 수정할 가능성이 생긴다. 실제로 운영 환경에서 이 방식은 권장되지 않는다.

따라서 권한을 제한하면서도 아파치와 일반 사용자 계정 간에 필요한 최소한의 접근을 허용하는 구조가 필요하다. 이 과정에서 고려한 방식이 그룹 기반 권한 공유와 mod-ruid2를 통한 사용자 권한 매핑이다.

mod-ruid2 기반 사용자 권한 매핑 구조

mod-ruid2는 아파치 모듈 중 하나로, 요청 단위로 프로세스의 실행 권한을 변경할 수 있도록 한다. 기본 구조에서는 모든 요청이 동일한 사용자로 처리되지만, 이 모듈을 사용하면 특정 디렉터리나 가상 호스트 단위로 사용자 계정을 지정할 수 있다.

동작 흐름은 다음과 같다. HTTP 요청이 들어오면 아파치는 해당 요청을 처리하기 전에 설정된 사용자로 권한을 전환한다. 이후 파일 접근, 스크립트 실행 등이 해당 사용자 권한으로 수행된다. 처리가 끝나면 다시 원래 권한으로 돌아간다.

설정은 다음과 같이 구성한다.

LoadModule ruid2_module modules/mod_ruid2.so

<IfModule mod_ruid2.c>
    RMode config
    RUidGid user apache
</IfModule>

입력으로 사용자(user)와 그룹(apache)을 지정하면, 요청 처리 시 해당 권한으로 실행된다. 결과적으로 /home/user 디렉터리의 파일 접근이 자연스럽게 이루어진다.

이 방식은 권한을 강제로 열어두지 않고, 실행 주체 자체를 변경하는 구조이기 때문에 파일 권한 관리 측면에서 명확한 경계를 유지할 수 있다.

그룹 기반 권한 공유와 디렉터리 설정 과정

mod-ruid2만으로 모든 문제가 해결되는 것은 아니다. 실제 파일 시스템 권한도 함께 정리해야 한다. 여기서는 그룹 기반 권한 공유 방식을 사용한다.

첫 번째 단계는 사용자와 아파치 계정을 동일 그룹으로 묶는 것이다.

usermod -a -G apache user

입력은 사용자 계정이며, 실행 결과로 해당 사용자가 apache 그룹에 포함된다. 이후 그룹 권한을 통해 파일 접근이 가능해진다.

두 번째 단계는 디렉터리 소유권을 변경한다.

chown -R user:apache /home/user

이 명령은 입력 경로의 모든 파일과 디렉터리의 소유자를 user, 그룹을 apache로 변경한다. 결과적으로 사용자와 아파치가 동일한 그룹 권한을 공유하게 된다.

세 번째 단계는 디렉터리 권한을 설정한다.

chmod 2775 /home/user
find /home/user -type d -exec chmod 2775 {} \;

여기서 2775는 setgid 비트를 포함한 권한이다. 새로 생성되는 파일과 디렉터리가 자동으로 apache 그룹을 상속받는다. 이 설정을 적용하지 않으면 이후 생성되는 파일이 다른 그룹으로 설정되어 접근 문제가 반복된다.

마지막으로 파일 권한을 조정한다.

find /home/user -type f -exec chmod 0664 {} \;

이 설정은 파일에 대해 소유자와 그룹에 읽기/쓰기 권한을 부여하고, 기타 사용자에게는 읽기 권한만 허용한다. 결과적으로 아파치와 사용자 모두 파일 수정이 가능하지만 외부 접근은 제한된다.

이 과정을 적용한 이후 테스트 기준으로 약 1,200개의 파일과 80개의 디렉터리 구조에서 권한 충돌 없이 동작하는 것을 확인했다.

권한 설정 방식 비교와 선택 기준

권한 설정 방식은 크게 세 가지로 나눌 수 있다. 첫 번째는 전체 권한 개방(chmod 777), 두 번째는 그룹 기반 공유, 세 번째는 사용자 권한 매핑이다.

전체 권한 개방은 설정이 단순하지만 보안 제어가 불가능하다. 테스트 환경에서는 빠르게 적용할 수 있지만 운영 환경에서는 사용하지 않는다.

그룹 기반 공유는 비교적 안정적인 방식이다. 동일 그룹 내에서만 접근이 가능하기 때문에 외부 접근을 차단할 수 있다. 다만 사용자와 서비스 계정 간 역할 구분이 명확하지 않을 수 있다.

mod-ruid2를 활용한 사용자 권한 매핑은 가장 명확한 방식이다. 요청 단위로 실행 권한이 변경되기 때문에 파일 소유권 구조를 그대로 유지할 수 있다. 대신 모듈 설치와 설정이 필요하며, 일부 환경에서는 호환성 문제가 발생할 수 있다.

선택 기준은 운영 환경의 구조에 따라 달라진다. 단일 사용자 기반의 서버라면 그룹 방식으로 충분하다. 반면 사용자별 웹 루트를 분리하는 경우에는 mod-ruid2 방식이 더 적합하다.

적용 시 주의사항과 운영 환경 고려 요소

이 방식은 권한을 명확하게 분리할 수 있다는 장점이 있지만 몇 가지 조건을 함께 고려해야 한다. 먼저 mod-ruid2는 MPM(Multi-Processing Module) 설정과 충돌할 수 있다. 특히 event MPM 환경에서는 정상 동작하지 않는 경우가 있어 prefork 기반으로 구성하는 것이 일반적이다.

또한 setgid 설정은 디렉터리 구조 전체에 영향을 주기 때문에, 특정 경로에만 적용하는 것이 필요하다. 전체 홈 디렉터리에 일괄 적용하면 예상하지 못한 권한 상속이 발생할 수 있다.

권한 변경 명령을 반복 실행할 경우 약 2,000개 이상의 파일에서 처리 시간이 3~5초 정도 소요된다. 배포 스크립트에 포함할 경우 이 부분도 고려해야 한다.

이 구조는 사용자별 웹 호스팅, 파일 업로드 처리, 로그 분리 환경에서 적용하기 적합하다. 반대로 단일 애플리케이션 서버에서는 오히려 복잡도를 높일 수 있기 때문에 필요 여부를 기준으로 적용하는 것이 맞다.