파일 모드 비트 대신 경로로 권한 부여

Question 1

이 개념을 파일이 포함된 디렉터리에서 기본적으로 권한을 상속하는 더 간단한 개념(아마도 설치별로)으로 바꿀 수 있는 방법이 있습니까?

예, 기본 ACL이라고 합니다.

[root@ditirlns02 acl-test]# setfacl -m d:u:jadavis6:rwx --mask .
[root@ditirlns02 acl-test]# getfacl .
# file: .
# owner: root
# group: root
user::rwx
group::r-x
other::r-x
default:user::rwx
default:user:jadavis6:rwx
default:group::r-x
default:mask::rwx
default:other::r-x

[root@ditirlns02 acl-test]# mkdir subDir
[root@ditirlns02 acl-test]# getfacl subDir
# file: subDir
# owner: root
# group: root
user::rwx
user:jadavis6:rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:user:jadavis6:rwx
default:group::r-x
default:mask::rwx
default:other::r-x
[root@ditirlns02 acl-test]# getfacl testFile
# file: testFile
# owner: root
# group: root
user::rw-
user:jadavis6:rwx               #effective:rw-
group::r-x                      #effective:r--
mask::rw-
other::r--
[root@ditirlns02 acl-test]# getfacl subDir/testFile
# file: subDir/testFile
# owner: root
# group: root
user::rw-
user:jadavis6:rwx               #effective:rw-
group::r-x                      #effective:r--
mask::rw-
other::r--
[root@ditirlns02 acl-test]# mkdir subDir/nestedDir
[root@ditirlns02 acl-test]# getfacl subDir/nestedDir
# file: subDir/nestedDir
# owner: root
# group: root
user::rwx
user:jadavis6:rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:user:jadavis6:rwx
default:group::r-x
default:mask::rwx
default:other::r-x

이는 번거로운 예이지만 기본 ACL이 생성 시 하위 디렉터리로 상속되고 디렉터리와 파일에 직접(유효한 ACE로) 적용된다는 점을 보여줍니다. 설계상 기본 ACL의 변경 사항은 적극적으로 전파되지 않습니다. Unix는 가능한 한 게으르게 노력하므로 이미 존재하는 파일에 새로운 권한을 적용하려면 조작 setfacl이나 chmod마법을 사용하게 될 것으로 예상됩니다. 자동 변경은 바람직하지도 않습니다. 실수로 파일이 너무 넓게 열렸다거나 현재 잠긴 응용 프로그램용 변경된 디렉터리 아래에 중첩된 특정 디렉터리를 관리자가 고려하지 않았다는 이야기를 자주 듣게 됩니다.

하지만 0777의 우마스크는 이런 식으로 제한되지 않는 곳에 큰 구멍을 열 위험이 있습니다.

글쎄, 이것은 첫 번째 요점과 실제로 관련이 없지만 POSIX ACL은 이 문제도 처리합니다. 권한 측면에서 ACL은 사용자 셸의 umask 설정보다 우선합니다. 실제로 ACL은 거부 권한을 마스크하고 umask는 권한을 부여하지 않아 암시적 거부가 발생하기 때문에 함께 작동합니다. 다음 명령을 사용하여 수정할 수 있습니다 setfacl.

[root@ditirlns02 acl-test]# setfacl -m m:r-x testFile
[root@ditirlns02 acl-test]# getfacl testFile
# file: testFile
# owner: root
# group: root
user::rw-
user:jadavis6:rwx               #effective:r-x
group::r-x
mask::r-x
other::r--

보시다시피, 내 개인 계정의 기본 DAC가 나를 "rwx"로 설정하더라도 내 계정은 여전히 "rx"만 얻습니다. ACL 마스크가 이러한 일이 발생하는 것을 방지하기 때문입니다. 다른 기본 ACL 항목처럼 기본 ACL 마스크를 관리할 수도 있습니다.

[root@ditirlns02 acl-test]# getfacl afterMask
# file: afterMask
# owner: root
# group: root
user::rwx
user:jadavis6:rwx               #effective:r-x
group::r-x
mask::r-x
other::r-x
default:user::rwx
default:user:jadavis6:rwx       #effective:r-x
default:group::r-x
default:mask::r-x
default:other::r-x

[root@ditirlns02 acl-test]# getfacl subDir
# file: subDir
# owner: root
# group: root
user::rwx
user:jadavis6:rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:user:jadavis6:rwx
default:group::r-x
default:mask::rwx
default:other::r-x

"자동 재계산 없음"이 실제로 작동하는 것을 볼 수 있도록 이전 디렉터리로 돌아갔습니다.

Again this won't work if people start moving files around

나는 조금 앞서 나가고 있으므로 이것이 이상적인 행동이 아닌 이유를 이미 설명했지만 자세히 설명할 수 있습니다. 기본적으로 기본 ACL을 변경하면 거의 항상 이미 존재하는 ACL을 변경하려고 합니다. 문제는 권한이 무엇인지 정확하게 예측하는 시스템을 설계할 수 없다는 것입니다. 이렇게 하면 다른 보안 및 안정성 문제에 직면하게 됩니다.

예를 들어:

/srv/applicationX/shares/accounting/deftManeuver다양한 시장에서 회사의 성과에 대한 독점 정보가 들어 있는 폴더가 있고 특정 사람만 해당 폴더에 액세스할 수 있습니다.
/srv/applicationX/shares는 Samba 또는 NFS를 통해 공유되며 회사 전체에서 사용됩니다.
새로운 부서가 시작되고 다양한 그룹 멤버십을 사용하려면 공유 디렉터리에 rwx를 제공해야 합니다.
이제 새 부서에서는 독점 정보에 액세스할 수 있습니다. 더 나쁜 것은 권한이 이런 식으로 설정되어 있다는 사실조차 깨닫지 못한다는 것입니다. 왜냐하면 어떤 일을 해야 했던 지 1년이 지났기 때문에 deftManeuver그것이 존재한다는 사실조차 잊어버렸기 때문입니다.

이는 다소 극단적인 예이지만 요점을 잘 보여줍니다. 권한이 그대로 유지된다면 플랫폼은 최소한 "좋아, 이 권한은사용된받아들일 수 있으므로 아마도 그들은 여전히 자신이 원하는 일에 꽤 근접해 있을 것입니다. ” 반면 Windows 세계에서는 존재하는지조차 모르는 파일에 대한 액세스 제어를 변경할 수 있습니다.

이 방법으로 deftManeuver한 번에 적절한 제한을 설정할 수 있으며, 이를 켜야 하는 경우 플랫폼은 "디렉토리 abc 및 그 하위 항목에 xyz를 원합니다"라고 명시적으로 말하도록 강제합니다. 플랫폼은 적어도 사용자가 그렇게 하지 않을 것이라는 내기를 헤지할 수 있습니다. 재귀 setfacl을 수행하고 있습니다.

이 기능은 직장 생활에서 여러 번 도움이 되었습니다. 문제를 해결하기 위해 너무 많은 디렉토리를 열었고 보안 담당자가 "안돼, 그러지 마"라고 말했고 전환 중에는새로운수년/수십년간 축적된 누적 정보가 아닌 파일의 권한이 안전하지 않습니다.

편집(선택적 ACL 호언장담):

이는 POSIX ACL에 실제 문제가 없다는 의미는 아닙니다. 여기에 나열된 반대 의견은 모델 내에서 처리되거나 버그가 아닌 기능일 뿐입니다.

일반 POSIX ACL의 문제점은 표현력입니다. 여전히 rwx만 얻을 수 있지만 타겟팅을 통해 더 많은 작업을 수행해야 합니다. Windows/NTFS는 이해되지 않는 사항(예: 마스크가 없는 기본 개념, 사용자별 삭제 권한 등)을 포함하여 권한에 대해 샷건 접근 방식을 취합니다. Unix와 같은 "파일 이름이 파일 이름이면 의미가 없습니다." 파일 이름 유지"). 파일이 비어 있으므로 "쓰기" 또는 권한 첨부 등으로 축소하지만 첨부 권한, 권한 변경 권한, 소유권 가져오기 권한 등과 같이 의미 있는 많은 항목이 포함되어 있습니다.

사용자별 또는 그룹별로 마스크를 설정할 수 없는 것과 같은 몇 가지 사소한 문제도 있습니다.

[root@ditirlns02 acl-test]# setfacl -m m:g:testGroup:rwx .
setfacl: Option -m: Invalid argument near character 3
[root@ditirlns02 acl-test]#

따라서 특정 유효 권한이 마스크를 초과하도록 명시적으로 허용할 방법이 없습니다(일반적인 규칙이 항상 그런 것은 아니며, 서로 다른 사용자 간에 긴 솔루션 중에서 결정하도록 강요하거나 너무 느슨한 마스크를 설정하도록 강요함). 일반적으로 어떤 경로가 사용되는지 추측해 보세요. 찍은...)

솔직히 말하면 아닌 것 같아누구나포괄적이고 표현적이며 안전한 방식으로 권한을 처리합니다.

Answer