개발자 도구 · Chmod 계산기
chmod 대 chown: 모드 변경이 종종 잘못된 레버인 이유
· 그것이 중요한 이유
chmod 유닉스 액세스 제어
모드 비트는 소유자 및 그룹과 관련된 것만을 의미합니다. 이 게시물에서는 두 명령을 분리하고 오류와 프로세스 ID 중에서 실제로 필요한 명령을 결정하는 방법을 보여줍니다.
명령 2개, 오류 1개 - 권한 거부 문제가 이번 달에 3개의 다른 chmod 및 chown 행으로 3번 '수정'되었습니다.
chmod 및 chown은 둘 다 권한 오류 근처에 나타나는 경우에도 서로 다른 정보를 처리합니다. 계산기는 소유자, 그룹 및 기타에 대한 권한 비트와 특수 비트를 모델링합니다. 현재 소유자나 그룹을 받지 않으며 소유권 작업을 수행하지 않습니다. 따라서 ID 관계가 알려지지 않고 테스트되지 않은 상태에서 모드가 올바르게 변환될 수 있습니다.
먼저 질문을 분리하세요. “750은(는) 무엇을 허용하나요?” 응답 가능: 소유자는 rwx를 얻고, 그룹은 r-x를 얻고, 다른 사람은 아무것도 얻지 못합니다. “이거 누구 소유야?” 그리고 “어떤 ID가 프로세스를 실행하나요?” 외부 증거가 필요합니다. ID를 확인하기 전에 모드를 편집하면 잘못된 클래스가 확대될 수 있습니다. 동기화된 뷰는 chmod와 소유권 변경 중에서 선택할 수 없습니다.
소유권이 먼저이고 그 다음 모드 — 커널이 비트를 확인하기 전에 프로세스에 대한 소유자, 그룹 또는 다른 사람을 선택하는 방법
클래스 선택은 ID에 따라 달라지며 계산기는 이를 받지 않습니다. 소유자, 그룹 및 기타 트리플은 검색된 계정이 아닌 카테고리입니다. 프로세스가 소유자와 일치하는지, 파일 그룹에 속하는지, 다른 그룹에 속하는지 알 수 없습니다. 이는 단순히 하나의 정수에서 세 가지 권한 집합을 모두 렌더링합니다. 자격 증명에는 외부 검사가 필요합니다.
따라서 관련성을 판단하기 위해서는 신원이 전제 조건입니다. 640 모드를 사용하면 소유자는 읽고 쓸 수 있고 그룹은 읽을 수 있으며 다른 사람은 아무것도 할 수 없습니다. 변환은 확실하지만 적용 가능한 트리플은 그렇지 않습니다. UID, 멤버십, 컨테이너 매핑 또는 ACL이 상태에 들어가지 않습니다. 먼저 이러한 사실을 확립한 다음 해당 비트를 평가하십시오.
클래스 선택은 ID에 따라 달라지며 계산기는 이를 받지 않습니다.
소유권 도구는 소유자 또는 그룹 관계를 차지하는 사람을 변경하는 반면, chmod는 해당 클래스에 연결된 권한을 변경합니다. 이 계산기는 chmod 측만 구현합니다. 8진수 또는 기호식 chmod 텍스트를 생성하고 chown 또는 chgrp를 내보내지 않습니다. 또한 파일을 변경하지 않습니다. 경로 필드는 외부 검토를 위해 인용된 미리보기만 작성합니다.
모드를 확장하면 소유권을 수정하지 않고도 추가 클래스를 노출할 수 있습니다. 750을 757과 비교하세요. 후자는 다른 읽기 및 실행을 추가합니다. 계산기는 해당 델타를 표시하지만 다른 계정의 혜택이나 소유권이 실패의 원인인지는 알 수 없습니다. 소유자, 그룹 및 프로세스 ID를 외부적으로 설정한 다음 의도한 클래스에만 필수 비트를 부여합니다.
공유 그룹 패턴 — 디렉터리의 chgrp와 setgid, 둘 다 쓰기가 필요한 두 사용자에 대한 표준 답변인 2775
공유 그룹 워크플로에는 외부 소유권 도구 및 정책이 필요합니다. 그룹 쓰기가 활성화되어 있으므로 사전 설정 775에는 "그룹과 공유됨"이라는 레이블이 지정됩니다. 사전 설정 2775은 setgid를 추가하여 rwxrwsr-x를 렌더링합니다. 디렉터리의 경우 새 파일은 디렉터리 그룹을 상속합니다. 이러한 비트 설명은 완전한 협업 설계 또는 배포 권장 사항을 구성하지 않습니다.
페이지에서는 그룹을 생성하거나, 구성원을 선택하거나, chgrp를 실행하거나 2775이 작업 부하에 적합하도록 설정할 수 없습니다. 또한 기본 ACL, umask 또는 애플리케이션 동작을 검사할 수 없습니다. 사전 설정을 정책이 아닌 산술 연산으로 처리합니다. 소유권과 멤버십을 다른 곳에서 확인한 다음 환경적 증거에 기초하여 실제 공유 디렉터리 설계를 기반으로 후보 모드를 비교합니다.
공유 그룹 워크플로에는 외부 소유권 도구 및 정책이 필요합니다.
다른 곳에서 소유권을 확인한 후 디렉터리 모드 750을 검사합니다. 소유자는 읽기, 쓰기 및 실행을 받습니다. 그룹은 읽기 및 실행을 수신합니다. 다른 사람은 아무것도 받지 않습니다. 그룹은 항목을 나열하고 입력할 수 있지만 항목을 생성하거나 이름을 바꾸거나 삭제할 수는 없습니다. 계산기는 실제 디렉터리나 계정을 검사하지 않고 rwxr-x--- 및 u=rwx,g=rx,o=를 렌더링합니다.
640에서 일반 파일을 별도로 검사합니다. rw-r----이 됩니다. 소유자 읽기 및 쓰기, 그룹 읽기, 기타 읽기는 불가능합니다. 페이지에 두 결과가 모두 표시되지만 이를 반복적으로 할당하거나 배포 계정을 식별하거나 서비스 그룹을 선택할 수는 없습니다. /var/www에 대한 적합성을 주장하려면 여기에 없는 작업 부하 및 신원 증거가 필요합니다.
작업 예: 소유권이 다른 곳에서 해결된 후 750 및 640을 검사합니다.
프로세스 ID 검색은 이 브라우저 도구 외부에 있습니다. 어떤 소스도 ps를 호출하고, 서비스 구성을 읽고, 컨테이너 네임스페이스를 검사하거나 계정 데이터베이스를 쿼리하지 않습니다. 계산기는 실행 중인 계정이나 보조 그룹을 식별할 수 없으므로 작업을 관리하는 권한 클래스를 결정할 수 없습니다. 해당 분류에는 담당 런타임 및 파일 시스템 환경의 최신 증거가 필요합니다.
외부적으로 아이덴티티가 확립되면 해당 클래스를 정확하게 검토합니다. 프로세스가 그룹 액세스를 사용해야 하는 경우 640는 해당 클래스에 읽기만 제공하고 쓰기는 제공하지 않는 반면 660은 그룹 쓰기를 추가합니다. 이 산술은 권장 사항이 아닙니다. 올바른 비트는 필요한 작업에 따라 다릅니다. 검색 및 정책을 변환기 외부에 유지하여 표현 실수를 방지합니다.
프로세스 ID 검색은 이 브라우저 도구 외부에 있습니다.
ACL 및 컨테이너 UID 매핑이 계산기에 없습니다. 해당 모델에는 세 가지 일반 클래스와 특수 비트가 포함되어 있지만 명명된 ACL 항목, 마스크 또는 네임스페이스 변환은 없습니다. 모드는 다른 레이어가 액세스를 제한하는 동안 충분해 보일 수도 있고 ACL이 확장하는 동안 제한적으로 보일 수도 있습니다. 제공된 정수만으로는 두 가지 가능성을 모두 해결할 수 없습니다.
입력이 누락되면 진단과 해결이 모두 제한됩니다. 경로는 chmod, chown, ACL 변경 또는 매핑 수정 중에서 선택할 수 없습니다. 제공된 기본 모드를 디코딩하고 s, S, t 및 T와 같은 특수 문자를 렌더링할 수 있습니다. 이를 제3자 또는 컨테이너 액세스에 대한 증거가 아닌 하나의 증거 레이어로 처리합니다.
요약: 비트보다 먼저 ID를 결정한 다음 Chmod 계산기를 사용하여 비트를 ID에 필요한 만큼 정확하게 만듭니다.
비트 이전에 동일성을 결정합니다. 모드는 소유자, 그룹 및 기타 클래스를 통해 작동하지만 계산기는 해당 클래스를 차지하는 계정보다는 권한을 알고 있습니다. 외부 검사를 통해 소유권과 프로세스 ID가 설정된 후 후보를 입력하고 각 의도된 읽기, 쓰기 및 실행 플래그를 확인합니다. 근처 값을 비교하면 명령이 브라우저를 떠나기 전에 실수로 확장되는 경우가 발생합니다.
최종 출력은 제안서로 유지됩니다. 페이지는 잘못된 입력을 거부하고, 8진수와 기호 형식을 동기화하고, 파일 및 디렉터리 의미를 설명하고, 경로를 인용하고, chmod 텍스트를 생성합니다. 명령을 실행하거나, 소유권을 변경하거나, ACL을 평가하거나, 정책을 검사하거나 애플리케이션을 테스트할 수는 없습니다. ID를 확정한 후 담당 시스템에서 제안된 변경 사항을 검증합니다.