Ubuntu 배포 서버에서 파일 권한을 숫자보다 소유자로 점검한 설정 노트

업로드 디렉터리만 실패했다

새 서버에서 애플리케이션은 정상 기동했지만 이미지 업로드 직후 500이 발생했다. 로그에는 permission denied가 있었고 정적 파일은 잘 읽혔다. 권한을 무작정 넓히기보다 프로세스의 계정부터 확인했다.

프로세스가 누구인지부터 확인

셸 계정은 ubuntu였지만 systemd 유닛은 www-data로 실행되고 업로드 디렉터리는 root:root였다.

systemctl show myapp --property=User,Group
ps -o user,group,cmd -C node
namei -l /srv/myapp/uploads
stat -c '%A %U:%G %n' /srv/myapp/uploads

기준은 애플리케이션 계정이 필요한 디렉터리만 쓸 수 있고 상위 경로는 통과할 수 있게 하는 것이었다.

install -d -o www-data -g www-data -m 0750 /srv/myapp/uploads
chown -R www-data:www-data /srv/myapp/uploads
find /srv/myapp/uploads -type d -exec chmod 0750 {} +
find /srv/myapp/uploads -type f -exec chmod 0640 {} +
su -s /bin/sh www-data -c 'test -w /srv/myapp/uploads'

다음 배포까지 생각하기

수동 수정만 하면 배포 때 root가 만든 파일로 다시 깨질 수 있다. 배포 스크립트에 소유권과 파일 모드 설정을 넣어 반복 가능한 상태로 만들었다.

배포 전 점검표

• systemd의 User/Group과 디렉터리 소유자가 맞는가
• namei -l로 상위 경로를 확인했는가
• 업로드 파일과 실행 파일의 모드를 구분했는가
• 서비스 계정으로 쓰기 테스트를 했는가

권한 문제를 숫자 하나로 덮지 않고 프로세스의 신원과 파일 생성 주체를 먼저 적으니 재발 원인까지 보였다.