☰

이 예에 대한 내 질문은 다음과 같습니다.

tag-icon • tag-icon filesystems kernel freebsd acl
이 예에 대한 내 질문은 다음과 같습니다.

FreeBSD에서 NFSv4 ACL을 사용하고 하위 파일+디렉터리(및 해당 하위 디렉터리의 하위/손자)의 상속된 ACL에 영향을 미치는 방식으로 디렉터리의 ACL을 변경하는 경우 다시 계산된 요점은 무엇입니까? ? 프로세스는 어떻게 관리되나요?

구체적인 예: 기존 디렉터리 계층 구조가 있고 특정 그룹에 대한 거부 또는 허용을 추가하는 새 ACL을 추가하고 싶다고 가정해 보겠습니다. 최상위 디렉터리에 대해 다음 명령 중 하나를 실행합니다.

  • setfacl -a 0 g:mygroup:dD:fd:deny /path_to_dir
  • setfacl -x g:mygroup:dD:fd:allow /path_to_dir

그러나 문서에서는 ACL 전파가 어떻게 작동하는지, 실제로 발생하는 시기 또는 발생 여부(또는 발생해야 하는 여부)가 명확하지 않습니다. 또한 잘못된 ACL을 사용하여 파일을 복사한 경우 상위 항목에서 ACL을 다시 계산하는 방법을 찾을 수 없거나 이러한 상황이 발생하더라도 마찬가지입니다.

이 예에 대한 내 질문은 다음과 같습니다.

  1. 단일 setfacl명령을 실행하는 것만으로도 이러한 규칙의 전파를 트리거하고 (필요한 경우) 계층 구조로 "계단식" 적용할 수 있습니다., 포함된 모든 객체의 권한/ACL이 업데이트되게 합니까?
  2. 또는 setfacl명령 중에 런타임 재계산이 필요하지 않습니까? 아마도 FreeBSD가 파일 액세스 중에 최상위 디렉토리에서 아래쪽으로 "즉시" ACL을 계산하기 때문일 것입니다., 유효한 ACL을 미리 계산 및 저장하고 ACL이 변경될 때 영향을 받는 모든 객체에 대해 이를 업데이트하는 대신?
  3. FreeBSD라면아니요명령이 실행될 때 아래쪽으로 계산되며 다음과 같은 경우 "즉시" 계산되지 않습니다.하다새 ACL은 전체 트리에 적용됩니다., 및/또는 트리 아래에서 더욱 효과적이게 하려면 어떻게 해야 합니까?
  4. 파일/디렉터리에 잘못된 ACL이 있는 경우 해당 파일의 모든 ACL을 명시적으로 정의하고 상속을 포기하는 유일한 솔루션이 있습니까?

도움이 되지 않는 답변:

전파가 문제이고 해결책이 필요한 경우 아마도 몇 가지 가능한 답변을 생각할 수 있지만 실제로 질문에 대한 답변은 아닙니다. 좋은 답변에 집중할 수 있도록 여기에 답변이 아닌 항목으로 표시하고 있습니다.

  1. find /path_to_dir -exec setfacl전파/재계산 문제를 해결하는 명시적 ACL을 수동으로 설정할 수 있다는 것을 알고 있습니다 . 그러나 이는 상속된 ACL을 명시적 ACL로 대체하는 것을 의미하므로 별로 도움이 되지 않습니다. 많은 클라이언트(특히 Windows)에서 명시적/상속된 ACL의 우선순위가 다르므로 이로 인해 ACL 계산 방법이 변경되고 이전에 유효했던 항목이 나중에 달라질 수 있습니다. 일을 깨는 것은 너무 쉽습니다. 이는 또한 너무 많은 ACL 설정이 상속되지 않은 상태로 전송되어 사례별로 확인해야 하기 때문에 감사 권한이 상속되지 않은 파일 + 디렉터리만 확인할 수 없음을 의미합니다. 기본적으로 "역겹다" :)
  2. 또 다른 가능한 대답은 영향을 받는 모든 파일/디렉터리를 복사하는 것일 수도 있다는 것도 알고 있습니다. 복제를 통해 처음부터 ACL을 생성하도록 강제할 수 있고 이러한 ACL은 최상위 디렉터리의 현재 ACL을 기반으로 하기 때문에 동일한 파일 시스템의 새로운 병렬 위치로 이동합니다. 실제로 ACL을 변경하기 위해 전체 파일 시스템의 복사본을 요구하는 것은 비현실적인 경우가 많기 때문에 이는 적용할 수 없습니다. 또한 작업을 중단하고, 중단하고, rsync/backups/snapshots를 엉망으로 만드는 것도 너무 쉽습니다(스냅샷과 함께 zfs를 사용하는 경우).

또한 여기서는 FreeBSD를 계속 사용하고 싶습니다. 왜냐하면 서로 다른 시스템이 매우 다른 방식으로 acl을 확인하고 업데이트할 수 있고, 제가 답변해야 하는 현재 시스템은 FreeBSD를 기반으로 하기 때문입니다.

답변1

이에 대한 문서가 확실히 부족합니다. 제가 아는 한, 제 경험에 따르면 다음과 같습니다.

setfacl특정 ACL(액세스 제어 목록)에 대한 ACE(액세스 제어 항목)를 추가, 수정 또는 삭제하기만 하면 됩니다. 다른 ACL의 다른 ACE는 일부가 변경된 ACE에서 상속되더라도 영향을 받지 않습니다. 다른 "상속된" ACE는 변경되지 않습니다.

ACE는 파일이나 디렉터리가 상속하는 경우에만 상속됩니다.건설되다.

f즉, ACE 또는 상속 비트가 설정된 ACE를 수정하는 경우 d해당 변경 사항을 이전에 상속된 항목으로 수동으로 "전파"하는 것은 사용자의 책임입니다(원하는 경우). 어떤 경우에는 그렇지 않을 수도 있습니다. 아마도 이것이 FreeBSD가 자동으로 이 작업을 수행하지 않는 이유일 것입니다.

예를 들어:

mkdir -p test_dir
getfacl test_dir
# file: test_dir
# owner: root
# group: wheel
#           owner@:rwxp--aARWcCos:-------:allow
#           group@:r-x---a-R-c--s:-------:allow
#        everyone@:r-x---a-R-c--s:-------:allow
setfacl -m g:staff:read_set:fd:allow test_dir # <- CREATE NEW ACE
getfacl test_dir
# file: test_dir
# owner: root
# group: wheel
#      group:staff:r-----a-R-c---:fd-----:allow <- NEW INHERITING ACE
#           owner@:rwxp--aARWcCos:-------:allow
#           group@:r-x---a-R-c--s:-------:allow
#        everyone@:r-x---a-R-c--s:-------:allow
mkdir -p test_dir/child_dir
getfacl test_dir/child_dir
# file: test_dir/child_dir
# owner: root
# group: wheel
#      group:staff:r-----a-R-c---:fd----I:allow <- NEW ACE INHERITED ON CREATE
#           owner@:rwxp--aARWcCos:-------:allow
#           group@:r-x---a-R-c--s:-------:allow
#        everyone@:r-x---a-R-c--s:-------:allow
touch test_dir/child_file
getfacl test_dir/child_file 
# file: test_dir/child_file
# owner: root
# group: wheel
#      group:staff:r-----a-R-c---:------I:allow <- NEW ACE INHERITED ON CREATE
#           owner@:rw-p--aARWcCos:-------:allow
#           group@:r-----a-R-c--s:-------:allow
#        everyone@:r-----a-R-c--s:-------:allow
setfacl -m g:staff:full_set:fd:allow test_dir # <- MODIFY ACE
getfacl test_dir
# file: test_dir
# owner: root
# group: wheel
#      group:staff:rwxpDdaARWcCos:fd-----:allow <- MODIFIED INHERITING ACE
#           owner@:rwxp--aARWcCos:-------:allow
#           group@:r-x---a-R-c--s:-------:allow
#        everyone@:r-x---a-R-c--s:-------:allow
getfacl test_dir/child_dir
# file: test_dir/child_dir
# owner: root
# group: wheel
#      group:staff:r-----a-R-c---:fd----I:allow <- DID NOT CHANGE
#           owner@:rwxp--aARWcCos:-------:allow
#           group@:r-x---a-R-c--s:-------:allow
#        everyone@:r-x---a-R-c--s:-------:allow
getfacl test_dir/child_file 
# file: test_dir/child_file
# owner: root
# group: wheel
#      group:staff:r-----a-R-c---:------I:allow <- DID NOT CHANGE
#           owner@:rw-p--aARWcCos:-------:allow
#           group@:r-----a-R-c--s:-------:allow
#        everyone@:r-----a-R-c--s:-------:allow

# MODIFY INHERITED ACEs TO MATCH MODIFIED INHERITING ACE
setfacl -m g:staff:full_set:fdI:allow test_dir/child_dir
setfacl -m g:staff:full_set:I:allow test_dir/child_file

따라서 귀하의 질문에 대답하려면 다음을 수행하십시오.

  1. setfacl기존 상속된 ACE는 변경되지 않습니다.
  2. FreeBSD는 즉석에서 아무것도 다시 계산하지 않습니다.
  3. 권한은 수동으로 설정된 경우에만 적용됩니다.
  4. 아니요, 명시적으로 표시할 필요는 없습니다. 귀하의 시나리오에서는 I상속된 ACE에 적용한 것과 동일한 수정 사항으로 기존의 상속된 ACE(플래그가 설정된 ACE)를 업데이트 할 수 있습니다 .

주의를 기울여야 할 두 가지 관련 FreeBSD 문제:

관련 정보