리눅스 명령어·권한·서비스 정리

umask는 왜 단순 뺄셈이 아닐까?

상위 디렉터리에 기본 ACL이 없고 생성 뒤 chmod도 하지 않습니다. 프로그램이 일반 파일에는 0666, 디렉터리에는 0777 권한을 요청할 때 umask 0027과 0013의 결과를 비교하세요. 숫자는 모두 8진수입니다.

Python 3

for mask in (0o027, 0o013):
    file_mode = 0o666 & (~mask & 0o777)
    directory_mode = 0o777 & (~mask & 0o777)
    print(f'{mask:03o} {file_mode:03o} {directory_mode:03o}')

풀이 순서

1. 새 권한은 요청 권한 AND (NOT umask)로 계산합니다. umask 027은 소유자는 그대로 두고, 그룹의 쓰기 비트와 기타 사용자의 모든 비트를 제거합니다.
2. umask 013에서 일반 파일의 그룹 권한은 6(110)입니다. 실행 비트 1(001)을 제거해도 6 그대로입니다. 기타 권한은 6(110)에서 3(011)의 비트를 제거하므로 4(100)입니다. 단순히 666−013을 하면 잘못된 653이 나옵니다.
3. umask는 없던 실행 권한을 추가하지 않습니다. 프로그램이 처음부터 0600만 요청했다면 더 넓은 결과가 나오지 않습니다. 기존 파일의 권한도 umask 변경만으로 바뀌지 않습니다.
4. 764 디렉터리에서 그룹은 이름 목록을 읽을 수 있지만 x가 없어 그 경로를 통과할 수 없습니다. 이름을 안다고 내부 파일을 열 수 있는 것은 아닙니다. 실제 접근에는 상위 경로 권한과 ACL 등도 영향을 줍니다.

확인 결과

027 640 750
013 664 764

틀리기 쉬운 지점: 디렉터리의 r은 이름 목록, x는 경로 탐색 권한입니다. 일반 파일의 내용 읽기·프로그램 실행과 같은 뜻으로 계산하지 마세요.

2>&1의 위치만 바꿨는데 오류 메시지가 파일에 안 남는 이유

Bash에서 emit 함수는 표준출력에 OUT, 표준오류에 ERR을 한 줄씩 씁니다. 아래 코드를 비어 있는 연습 디렉터리에서 실행하면 화면과 두 파일에 각각 무엇이 남을까요? all.log와 out.log가 이미 있으면 덮어쓰므로 기존 자료가 있는 곳에서는 실행하지 마세요.

Bash

emit() {
  printf 'OUT\n'
  printf 'ERR\n' >&2
}
emit > all.log 2>&1
emit 2>&1 > out.log

넓은 표는 좌우로 밀어 나머지 열을 볼 수 있습니다.

풀이 순서

1. 첫 명령은 1번을 all.log에 연결한 다음 2번도 그 목적지에 연결합니다. OUT과 ERR이 모두 같은 파일에 순서대로 기록됩니다.
2. 두 번째 명령은 2번을 당시 1번의 목적지인 화면에 연결합니다. 이후 1번만 out.log로 바뀌므로 ERR은 화면에 남습니다. 2>&1은 앞으로의 1번 변경을 따라가는 지속적인 연결이 아닙니다.
3. 두 번째 경우 ERR은 터미널에 보이지만 셸이 물려준 표준출력 경로로 갑니다. 상위 프로그램에서 stdout과 stderr를 따로 수집할 때도 이 차이가 나타납니다. 위 확인 결과는 전체 스크립트가 화면에 출력한 한 줄입니다.

확인 결과

ERR

틀리기 쉬운 지점: 2>&1과 > 파일은 순서를 바꿔도 같은 옵션 묶음이 아닙니다. 셸이 왼쪽부터 파일 디스크립터 연결을 바꾼다는 점을 먼저 적용하세요.

검증 방법과 참고 문서

권한은 Python 비트 계산과 각 r/w/x 비트의 독립 대조로 확인했습니다. 리다이렉션 코드는 격리된 임시 디렉터리에서 Bash로 실행해 stdout·stderr·두 파일 내용을 비교했습니다. Linux 서비스나 실제 사용자 파일의 권한을 바꾸는 실험은 하지 않았습니다.

예제·데이터·풀이표: 정처LAB 자체 설계 · AI 보조 작성 및 로컬 검증 · 예제 수정일 2026-09-27

• Linux man-pages — umask와 기본 ACL
• GNU Bash — 리다이렉션 처리 순서