그룹의 chmod (1)가 ACL 마스크에 영향을주는 이유는 무엇입니까?

이 유닉스 동작을 이해하려고합니다 (우분투 11.10에서 테스트 중입니다).

$ touch foo
$ setfacl -m u:nobody:rwx foo
$ getfacl foo
# file: foo
# owner: michael
# group: michael
user::rw-
user:nobody:rwx
group::rw-
mask::rwx
other::r--

$ chmod g-rw foo
$ getfacl foo
# file: foo
# owner: michael
# group: michael
user::rw-
user:nobody:rwx         #effective:--x
group::rw-          #effective:---
mask::--x
other::r--

chmod (1) 명령이 ACL 마스크를 업데이트했습니다. 왜 이런 일이 발생합니까?

SunOS의 맨 페이지는 말할 다음이있다 :

chmod (1) 명령을 사용하여 ACL 항목이있는 파일의 파일 그룹 소유자 권한을 변경하면 파일 그룹 소유자 권한과 ACL 마스크가 모두 새 권한으로 변경됩니다. 새 ACL 마스크 권한은 파일에 ACL 항목이있는 추가 사용자 및 그룹에 대한 유효 권한을 변경할 수 있습니다.

chmod (1)에이 동작이 없으면 편리 할 것이기 때문에 묻습니다. 왜 그 기능을 수행하는지 이해함으로써 파일 시스템 권한을 설정하는 방법을 더 잘 설계 할 수 있기를 바랍니다.

그것은 것 없는 경우에 당신을 위해 편리 할 chmod()이 동작을하지 않았다.

사람들이 전통적으로 유닉스에 대한 작업을 기대하는 것이 깨질 수 있기 때문에 매우 불편합니다. 이 행동은 당신에게 잘 도움이됩니다.

IEEE 1003.1e가 표준이되어 1998 년에 철회 된 것은 부끄러운 일입니다. 실제로 14 년이 지난 지금은 Linux 에서 FreeBSD , Solaris에 이르기까지 광범위한 운영 체제가 실제로 구현 하는 표준입니다 .

IEEE 1003.1e 실무 초안 # 17은 흥미로운 독서를하도록 권장합니다. 부록 B § 23.3에서 실무 그룹은 POSIX ACL이 이전 S_IRWXG그룹 권한 플래그 와 관련하여 작동하는 다소 복잡한 방식에 대한 자세한 8 페이지 근거를 제공합니다 . (TRUSIX 사람들이 10 년 전에 똑같은 분석을 제공했다는 점은 주목할 가치가 있습니다.) 나는 여기에 모든 것을 복사하지는 않을 것입니다. 자세한 내용은 표준 초안의 이론적 근거를 읽으십시오. 다음은 매우 간단한 précis입니다 .

• SunOS 매뉴얼이 잘못되었습니다. 그것은 해야 읽기

  당신이 사용하는 경우 chmod(1), ACL 항목이있는 파일의 파일 그룹 소유자 권한을 변경하는 명령을 하나 의 파일 그룹 소유자 권한 또는 ACL에 마스크를 새로운 권한 변경됩니다.

  이것은 당신이 할 수있는 동작입니다 해프닝을 볼 수 귀하의 질문에, 현재 매뉴얼 페이지의 말씀에도 불구하고. POSIX 표준 초안에서 지정한 동작이기도합니다. 경우 CLASS_OBJ(Sun의 및 TRUSIX의 용어에 대한 ACL_MASK) 액세스 제어 항목이 존재하는의 그룹 비트 chmod()세트는, 그렇지 않으면 그들은 설정 GROUP_OBJ액세스 제어 항목을.

• 그렇지 않은 경우,`chmod ()`를 사용하여 다양한 표준 작업을 수행 한 응용 프로그램은`chmod ()`가 기존의 비 ACL Unix에서 작동했던 것으로 예상되었으므로 보안 허점을 남기거나 그들은 보안 허점을 생각합니다.

  • 전통적인 유닉스 응용 프로그램은 파일, 파이프, 장치 또는 디렉토리를 사용하여 파일에 대한 모든 액세스를 거부 할 수있을 것으로 기대합니다 chmod(…,000). ACL이있는 경우, 이전 맵이에 매핑 된 경우 모든 사용자 및 그룹 권한 만 끕니다 . 이것이 없으면 이전 파일 권한을 설정해도 항목 이나 항목에 영향을 미치지 않으며 다른 사용자도 놀랍게도 여전히 개체에 액세스 할 수 있습니다.S_IRWXGCLASS_OBJ000USERGROUP

    일시적으로 액세스 할 수 없음에 파일의 권한 비트를 변경 chmod 000한 후 다시 그들을 다시 변경하면 유닉스는 것을, 자문 잠금 메커니즘을 얻었다 이전에 사용, 오래된 파일 잠금 메커니즘이었다 당신이 볼 수있는 - - 사람들이 오늘날에도 여전히 사용 .

  • 전통적인 유닉스 스크립트 chmod go-rwx는 객체의 소유자 만이 객체에 접근 할 수있게되어 실행 되고 끝날 수있을 것으로 기대 합니다. 다시 한 번 , 알 다시피 , 이것은 12 년이 지난 지금도 여전히받은 지혜 입니다. 다시 말하지만, 이전 명령이 존재 S_IRWXG하는 CLASS_OBJ경우 매핑 되지 않는 한 작동하지 않습니다. 그렇지 않으면 해당 chmod명령이 액세스 제어 항목을 끄지 USER않거나 GROUP소유자 및 비 소유 그룹 이외의 사용자 가 예상 액세스 할 경우에만 소유자.

  • 권한 비트가 andACL 과 분리되어 ACL과 함께 사용되는 시스템 rwxrwxrwx은 대부분의 경우 파일 권한 플래그가 필요하며 , 이는 세계에서 쓸 수 있다고 생각되는 것을 볼 때 불평하는 많은 유닉스 응용 프로그램의 혼란을 혼란스럽게합니다. 물건.

    권한 비트가 orACL 과 분리되어 ACL과 함께있는 시스템은 chmod(…,000)앞에서 언급 한 문제 가 있습니다 .

추가 자료

• Winfried Trümper (1999-02-28). Posix.1e에 대한 요약
• IEEE 컴퓨터 협회의 휴대용 응용 표준위원회 (1997 년 10 월). 정보 기술에 대한 표준 초안 — 휴대용 운영 체제 인터페이스 (POSIX) — 제 1 부 : 시스템 응용 프로그램 인터페이스 (API) — 개정 번호 : 보호, 감사 및 제어 인터페이스 [C 언어] IEEE 1003.1e. 초안 17.
• 크레이그 루빈 (1989-08-18). 유닉스 시스템에 대한 액세스 제어 목록 기능 선택의 근거 . NCSC-TG-020-A. 다이아몬드 출판. ISBN 9780788105548.

이 동작은 POSIX ACL 항목에만 적용됩니다. 폴더가 있고 해당 폴더 안에 파일이 있으면 폴더와 파일을 rwx (예 : acl)로 지정할 수 있습니다. 파일의 그룹 권한이 rw- 인 경우 (일반적인 시나리오 일 수 있음) ACL이 ACL에 명시 적으로 rwx를 표시하더라도 마스크에 acl에 rw의 유효 권한이 부여됩니다.

반면, 거의 항상 + x 인 디렉토리에는 + x를 허용하는 효과적인 ACL 마스크 권한이 있습니다.

요약하면,이 마스크는 기본적으로 POSIX ACL 세트에 대한 파일과 폴더 간 권한을 구별하여 파일이 정상적으로 실행되지 않아야 할 때 파일이 실행되지 않도록하는 데 사용됩니다.