Ubuntu에서 배포 계정의 파일 권한을 755로 통일하지 않은 이유

권한 오류의 응급처치가 또 다른 오류를 만들었다

배포 계정으로 정적 파일을 올린 뒤 웹 서버가 읽지 못하자 예전에는 디렉터리 전체에 chmod -R 755를 실행했다. 페이지는 열렸지만 설정 파일까지 다른 사용자가 읽을 수 있게 될 수 있다는 사실을 뒤늦게 확인했다. 실행할 필요 없는 파일에도 x 비트가 붙었다.

권한 숫자 하나로 해결하려 하지 않고, 누가 소유하고 어떤 프로세스가 읽어야 하는지로 나눠 봤다.

644, 755, 640은 역할이 다르다

대상	보통 필요한 권한	이유
일반 파일	644	소유자는 수정, 웹 서버는 읽기
접근해야 하는 디렉터리	755 또는 그룹 기반 750	디렉터리 진입에 x 권한 필요
비밀 설정 파일	600 또는 640	불필요한 읽기 차단
실행 스크립트	750 또는 755	정말 실행할 파일만 x 부여

웹 서버 사용자와 배포 사용자를 같은 그룹에 두는 방식이 필요할 때도 있다. 그 경우 소유자만 바꾸기보다 그룹과 기본 권한을 명시했다.

sudo chgrp -R webdeploy /var/www/app
sudo find /var/www/app -type d -exec chmod 2750 {} \;
sudo find /var/www/app -type f -exec chmod 0640 {} \;

디렉터리의 2는 setgid 비트라 새 파일도 webdeploy 그룹을 이어받는다. 단, 애플리케이션이 업로드 파일을 쓰는 경로와 읽기만 하는 빌드 결과물 경로는 분리했다. 모두에게 쓰기 권한을 주는 777은 해결책이 아니다.

확인은 실제 사용자로 했다

root에서 ls가 되는 것은 의미가 작았다. Nginx 또는 서비스 계정이 읽을 수 있는지 확인해야 했다.

namei -l /var/www/app/.next/static
sudo -u www-data test -r /var/www/app/index.html && echo readable

namei -l은 경로 중간 디렉터리의 x 권한이 빠진 경우를 찾는 데 특히 유용했다. 파일 자체는 644인데 상위 디렉터리를 통과하지 못해 403이 난 적이 있었다.

나의 적용 기준

권한 에러가 나면 이제 다음 순서를 따른다: 실행 중인 서비스 사용자 확인 → 경로 모든 단계의 소유자와 권한 확인 → 필요한 최소 권한만 부여 → 배포 후 실제 사용자로 테스트. 숫자를 통일하는 것보다 이 순서가 재발을 막았다.