chown(1) POSIX 사양에 대한 설명

Question 1

그만큼Microsoft Interix Unix 하위 시스템 (현재는 은퇴)NT 커널의 경우 다른 커널과 달리 사용자 및 그룹 권한을 약간 다르게 처리했습니다.

사용자 및 그룹 정보는보안 액세스 데이터베이스. 사용자와 그룹은 모두 동일한 데이터베이스에 저장되지만 그룹과 사용자 이름은 고유해야 합니다. 어떤 그룹도 사용자 이름을 가질 수 없으며 그 반대의 경우도 마찬가지입니다.(이 데이터베이스는 UNIX의 /etc/passwd및 파일을 대체합니다.)/etc/groups사용자 및 그룹은 적절한 Windows 방법을 사용하여 생성됩니다.(사용자 관리자, Active Directory 사용자 및 컴퓨터, 또는 로컬 사용자 및 그룹)또는 Win32 net user명령을 사용합니다.(사용자를 생성하고 제거하는 예제 쉘 스크립트는 디렉토리에 포함되어 있습니다 /usr/examples/admin.)사용자는 여러 그룹에 속할 수 있습니다.

여기 있습니다일부보다 구체적인 매뉴얼 발췌:

Windows에서는 사용자나 그룹이 개체를 소유할 수 있습니다. 이는 사용자만이 객체를 소유하는 UNIX와 다릅니다.

Windows는 보안 식별자를 사용하여 내부적으로 모든 사용자와 그룹을 식별합니다.(시드). 해싱 알고리즘은 고유한 SID 값을 생성합니다. 두 사용자 또는 그룹은 동일한 SID를 갖지 않습니다.

개체에 액세스할 수 있는 권한이 있는 사용자와 그룹은 해당 SID로 식별됩니다. Windows에서 보호할 수 있는 모든 개체에는 ACE(액세스 제어 항목)라는 별도의 항목으로 구성된 DACL(임의 액세스 제어 목록)이 있습니다. ACE에는 사용자 또는 그룹 SID와 개별 사용자 또는 그룹이 개체에 대해 갖는 액세스 권한에 대한 설명이라는 두 가지 중요한 정보가 포함되어 있습니다.

CHGRP

...파일의 그룹 ID 변경 ... chgrp(1)을 호출하는 사용자는 지정된 그룹에 속해야 하고 파일의 소유자이거나 적절한 권한을 가지고 있어야 합니다.

초운

...소유자와 그룹 피연산자는 모두 선택 사항입니다. 그러나 하나를 지정해야 합니다. 그룹 피연산자를 지정하는 경우 앞에 콜론(:)이 와야 합니다.

소유자는 숫자 사용자 ID 또는 사용자 이름으로 지정할 수 있습니다. 사용자 이름이 숫자 사용자 ID이기도 하면 피연산자가 사용자 이름으로 사용됩니다. 그룹은 숫자 그룹 ID 또는 그룹 이름일 수 있습니다. 그룹 이름이 숫자 그룹 ID이기도 하면 피연산자가 그룹 이름으로 사용됩니다.

보안상의 이유로 파일의 소유권은 적절한 권한이 있는 프로세스에 의해서만 변경될 수 있습니다.

chgrp제가 읽은 바에 따르면 귀하의 사용자 계정이 해당 그룹이 소유한 파일의 권한을 수정할 수 있는 충분한 권한을 가진 Windows 그룹에 속해 있으면 해당 파일을 귀하의 사용자 계정 제어 외부에서 효과적으로 사용할 수 있다는 의미입니다 . 이는 chown명시적 매개변수를 사용하여 가질 수 있는 것보다 제어력이 떨어집니다 user:group. 그 맥락에서 선언할 가능성 없이user: 그리고 :group그렇지 않으면 결코 동일한 결과를 얻을 수 없습니다.

여기 링크가 있습니다Interix가 Windows ACL과 상호 작용하는 방법을 자세히 살펴보고 이러한 지식이 다른 Unix 변형의 Samba 파일 시스템에 어떻게 적용될 수 있는지에 중점을 둡니다.

여기 링크가 있습니다지금으로쓸모없는rstchown튜너 블을 설명하는 Solaris 문서

시스템 호출 에 대한 POSIX 의미 체계가 chown(2)유효한지 여부를 나타냅니다.

분명히 매개 변수가 다음 값으로 설정되면 0...

...POSIX 의미 체계를 끄면 다양한 보안 허점이 발생할 가능성이 있습니다. 이는 또한 다음과 같은 가능성을 열어줍니다.사용자가 파일 소유권을 다른 사용자로 변경하고 파일을 검색할 수 없음사용자나 시스템 관리자의 개입 없이 다시 돌아옵니다.

이러한 옵션은 Solaris의POSIX 적합성. 그것이 옵션이라는 것만으로도 자격이 있습니다.적합하다:

POSIX.1-2008을 준수하는 모든 구현은 아래 설명된 모든 기능을 지원하지만제거하거나 수정할 수 있는 시스템 종속 또는 파일 시스템 종속 구성 절차 이러한 기능 중 일부 또는 전부. 엄격한 준수가 필요한 경우에는 이러한 구성을 수행해서는 안 됩니다.

다음 기호 상수는 -1이 아닌 값으로 정의되어야 한다. 상수가 0 값으로 정의된 경우 응용 프로그램은 , 또는 함수나 유틸리티를 사용하여 sysconf()해당 pathconf()시점 fpathconf()에 getconf시스템에 어떤 기능이 있는지 또는 문제의 특정 경로 이름에 대해 존재하는지 확인해야 합니다.

_POSIX_CHOWN_RESTRICTED

의 사용은 chown()적절한 권한이 있는 프로세스로 제한되며, 파일의 그룹 ID를 프로세스의 유효 그룹 ID 또는 보조 그룹 ID 중 하나로만 변경하는 것으로 제한됩니다.

시스템 chown()기능 - 이는 두 가지 모두에 의해 수행되는 문서화된 시스템 호출입니다.chown그리고chgrp쉘 유틸리티 -실패하도록 지정됨여러 가지 이유로. 그 중에는:

EACCES 경로 접두사의 구성 요소에 대한 검색 권한이 거부되었습니다.

ELOOP 경로 인수를 확인하는 동안 발견된 기호 링크에 루프가 있습니다.

EPERM 유효 사용자 ID가 파일 소유자와 일치하지 않거나 호출 프로세스에 적절한 권한이 없으며_POSIX_CHOWN_RESTRICTED해당 권한이 필요함을 나타냅니다.

그러나 루트가 아닌 사용자에게 권한 수정 권한을 부여하는 동작은 Solaris에만 국한된 것이 아닙니다. 있다매우 훌륭하다- 다소 오래된 경우 - Unix 파일 권한에 대한 내용은 다음과 같습니다.이 포럼 게시물저자는 다음과 같이 말합니다.

원래 유닉스에서는 파일 소유자가 파일을 다른 사람에게 양도하는 것을 허용했습니다. 파일 소유자는 소유자를 다른 사람으로 변경할 수 있습니다. 루트가 아닌 사용자가 이 작업을 취소할 수 있는 방법은 없었습니다... BSD[나중에]chown루트가 아닌 사용자에게서 제거됨...[일부 이유는]...사용자가 파일 시스템에서 가질 수 있는 디스크 공간의 양을 제한할 수 있는 디스크 할당량을 구현했습니다. 버릇없는 사용자는 할당량을 몰래 넘기기 위해 대용량 파일을 제공할 수 있습니다.

chown오늘날에는 루트가 아닌 사람 도 파일을 사용할 수 있는지 말하기가 쉽지 않습니다 . 많은 Unix 버전에서는 다음을 허용합니다.둘 다행동...

또 다른 좋은 - 그리고 더 최근의 -메일링 리스트 게시물이것을 인용하고 계속합니다.

대부분의 OS의 기본값은 chown루트로만 제한되는 것입니다. 그리고 보안을 고려하여 이 방식을 유지해야 한다는 합의가 있습니다. 루트가 아닌 사용자가 파일 소유자를 변경하고 실행 비트가 켜져 있는 경우 SUID및 SGID비트를 지워야 합니다. 이는 에서 발생할 수도 있고 발생하지 않을 수도 있습니다 root.

마지막 문단이 그 말을 잘 표현하고 있는 것 같아요.

해당 기사에는 CAP_CHOWNLinux에서 해당 기능을 제어하는 방법 도 언급되어 있습니다.(행동에만 영향을 주어야 함 POSIX_CHOWN_RESTRICTED). CAP_FOWNER동작이 약간 다른 기능 도 있습니다 .

그리고2003년에 당신이 지적한:

적어도 HPUX에서는 파일 소유자를 변경할 수 있습니다.( root예를 들어)권한이 있는 사용자가 아니더라도...

...구성 setprivgroup매개변수에 따라 달라집니다.

루트가 아닌 사용자가 파일 권한을 조작할 수 있는 경우에는 다음에서 언급한 것처럼 생각할 수 있습니다.이론적 해석귀하의 질문에 인용된 내용에 따르면, 사용자는 chown해당 사용자가 소유한 파일을 다른 사용자가 소유하게 될 수 있습니다. 파일의 그룹 소유권과 chowning 사용자의 그룹이 일치하지 않으면 사용자는 더 이상 해당 파일을 수정할 수 없습니다.

이 시나리오에서는chown 그 다음에 chgrp사용자가 더 이상 해당 파일의 권한을 변경할 권한이 없기 때문에 실패합니다 chown user:group.그룹사용자 자신의 것 중 하나입니다. 성공할 것입니다.

있다아마유사하게 발생할 수 있는 기타 여러 틈새 상황(예: 디렉토리 포함)어려운및/또는설정비트, 파일 시스템 및/또는 구현별 액세스 제어 목록.이 스레드예를 들어 흥미롭습니다. 셀 수 없이 많은 순열은 내 자신의 미약한 이해 범위를 훨씬 뛰어넘는 것입니다. 이것이 바로 이 답변이 위키에 있는 이유입니다. 이 글을 읽고 계시다면 개선할 가치가 있다고 믿으실 것이며, 방법도 알고 계시리라 믿습니다.제발.

-R또한 여기에서는 순환적 chown애플리케이션 과 관련하여 유사한 실패에 영향을 미칠 수 있는 파일 권한, 트리 순회 및 기호 링크의 다양한 효과에 대한 광범위한 문서도 있습니다 .

에서POSIX XRAT섹션 제목제삼그리고네 번째 도메인:

일반적으로 파일 계층 탐색 옵션을 지정하는 사용자는 단일 물리적 계층에서 작업하기를 원하므로 계층 외부의 파일을 참조할 수 있는 심볼릭 링크는 무시됩니다. 예를 들어, chown owner file은 -R 옵션이 지정된 동일한 명령과 다른 작업입니다. 이 예에서는 명령의 동작이 chown owner file설명되어 있지만 명령의 동작은 다음과 같습니다.chown -R소유자 파일은 세 번째와 네 번째 도메인에 설명되어 있습니다.

...논리적 보행을 기본값으로 설정하면 보안 문제가 있습니다. 역사적으로 명령은chown -R사용자 파일은 슈퍼유저에게 안전합니다.세트이드그리고설정파일의 소유권이 변경되면 비트가 손실되었습니다. 탐색이 논리적인 경우 사용자가 트리의 모든 파일을 가리키는 기호 링크를 삽입했을 수 있으므로 소유권 변경은 더 이상 안전하지 않습니다. 다시 말하지만, 이는 기호 링크를 통해 간접적으로 접근하지 않도록 계층 순회를 수행하는 명령에 옵션을 추가해야 하며 재귀 탐색을 수행하는 기록 스크립트는 즉시 보안 문제가 될 수 있습니다. 이는 대부분 시스템 관리자의 문제이지만 사용자 클래스에 따라 기본값을 다르게 설정하지 않는 것이 좋습니다.

...

4.3 BSD에서는 chgrp트리 순회 중에 대상이 아닌 기호 링크 그룹이 변경되었습니다. 4.4 BSD의 심볼릭 링크에는 소유자, 그룹, 모드 또는 기타 표준 UNIX 시스템 파일 속성이 없습니다.

그리고 POSIX에서chgrp페이지에 불완전한 재귀적 작업이 있을 수 있음을 가리키는 내용이 있습니다. -R또는 적어도 무엇을 의미합니까?사용된장차 ~ 가 되는:

System V와 BSD 버전은 서로 다른 종료 상태 코드를 사용합니다. 일부 구현에서는 종료 상태를 발생한 오류 수의 개수로 사용했습니다. 이 방법은 유효한 종료 상태 값의 범위를 오버플로할 수 있으므로 실행 불가능합니다. 표준 개발자는 종료 값으로 0과 >0만 지정하여 이를 마스크하기로 결정했습니다.

Answer

그만큼Microsoft Interix Unix 하위 시스템 (현재는 은퇴)NT 커널의 경우 다른 커널과 달리 사용자 및 그룹 권한을 약간 다르게 처리했습니다.

사용자 및 그룹 정보는보안 액세스 데이터베이스. 사용자와 그룹은 모두 동일한 데이터베이스에 저장되지만 그룹과 사용자 이름은 고유해야 합니다. 어떤 그룹도 사용자 이름을 가질 수 없으며 그 반대의 경우도 마찬가지입니다.(이 데이터베이스는 UNIX의 /etc/passwd및 파일을 대체합니다.)/etc/groups사용자 및 그룹은 적절한 Windows 방법을 사용하여 생성됩니다.(사용자 관리자, Active Directory 사용자 및 컴퓨터, 또는 로컬 사용자 및 그룹)또는 Win32 net user명령을 사용합니다.(사용자를 생성하고 제거하는 예제 쉘 스크립트는 디렉토리에 포함되어 있습니다 /usr/examples/admin.)사용자는 여러 그룹에 속할 수 있습니다.

여기 있습니다일부보다 구체적인 매뉴얼 발췌:

Windows에서는 사용자나 그룹이 개체를 소유할 수 있습니다. 이는 사용자만이 객체를 소유하는 UNIX와 다릅니다.

Windows는 보안 식별자를 사용하여 내부적으로 모든 사용자와 그룹을 식별합니다.(시드). 해싱 알고리즘은 고유한 SID 값을 생성합니다. 두 사용자 또는 그룹은 동일한 SID를 갖지 않습니다.

개체에 액세스할 수 있는 권한이 있는 사용자와 그룹은 해당 SID로 식별됩니다. Windows에서 보호할 수 있는 모든 개체에는 ACE(액세스 제어 항목)라는 별도의 항목으로 구성된 DACL(임의 액세스 제어 목록)이 있습니다. ACE에는 사용자 또는 그룹 SID와 개별 사용자 또는 그룹이 개체에 대해 갖는 액세스 권한에 대한 설명이라는 두 가지 중요한 정보가 포함되어 있습니다.

CHGRP

...파일의 그룹 ID 변경 ... chgrp(1)을 호출하는 사용자는 지정된 그룹에 속해야 하고 파일의 소유자이거나 적절한 권한을 가지고 있어야 합니다.

초운

...소유자와 그룹 피연산자는 모두 선택 사항입니다. 그러나 하나를 지정해야 합니다. 그룹 피연산자를 지정하는 경우 앞에 콜론(:)이 와야 합니다.

소유자는 숫자 사용자 ID 또는 사용자 이름으로 지정할 수 있습니다. 사용자 이름이 숫자 사용자 ID이기도 하면 피연산자가 사용자 이름으로 사용됩니다. 그룹은 숫자 그룹 ID 또는 그룹 이름일 수 있습니다. 그룹 이름이 숫자 그룹 ID이기도 하면 피연산자가 그룹 이름으로 사용됩니다.

보안상의 이유로 파일의 소유권은 적절한 권한이 있는 프로세스에 의해서만 변경될 수 있습니다.

chgrp제가 읽은 바에 따르면 귀하의 사용자 계정이 해당 그룹이 소유한 파일의 권한을 수정할 수 있는 충분한 권한을 가진 Windows 그룹에 속해 있으면 해당 파일을 귀하의 사용자 계정 제어 외부에서 효과적으로 사용할 수 있다는 의미입니다 . 이는 chown명시적 매개변수를 사용하여 가질 수 있는 것보다 제어력이 떨어집니다 user:group. 그 맥락에서 선언할 가능성 없이user: 그리고 :group그렇지 않으면 결코 동일한 결과를 얻을 수 없습니다.

여기 링크가 있습니다Interix가 Windows ACL과 상호 작용하는 방법을 자세히 살펴보고 이러한 지식이 다른 Unix 변형의 Samba 파일 시스템에 어떻게 적용될 수 있는지에 중점을 둡니다.

여기 링크가 있습니다지금으로쓸모없는rstchown튜너 블을 설명하는 Solaris 문서

시스템 호출 에 대한 POSIX 의미 체계가 chown(2)유효한지 여부를 나타냅니다.

분명히 매개 변수가 다음 값으로 설정되면 0...

...POSIX 의미 체계를 끄면 다양한 보안 허점이 발생할 가능성이 있습니다. 이는 또한 다음과 같은 가능성을 열어줍니다.사용자가 파일 소유권을 다른 사용자로 변경하고 파일을 검색할 수 없음사용자나 시스템 관리자의 개입 없이 다시 돌아옵니다.

이러한 옵션은 Solaris의POSIX 적합성. 그것이 옵션이라는 것만으로도 자격이 있습니다.적합하다:

POSIX.1-2008을 준수하는 모든 구현은 아래 설명된 모든 기능을 지원하지만제거하거나 수정할 수 있는 시스템 종속 또는 파일 시스템 종속 구성 절차 이러한 기능 중 일부 또는 전부. 엄격한 준수가 필요한 경우에는 이러한 구성을 수행해서는 안 됩니다.

다음 기호 상수는 -1이 아닌 값으로 정의되어야 한다. 상수가 0 값으로 정의된 경우 응용 프로그램은 , 또는 함수나 유틸리티를 사용하여 sysconf()해당 pathconf()시점 fpathconf()에 getconf시스템에 어떤 기능이 있는지 또는 문제의 특정 경로 이름에 대해 존재하는지 확인해야 합니다.

_POSIX_CHOWN_RESTRICTED

의 사용은 chown()적절한 권한이 있는 프로세스로 제한되며, 파일의 그룹 ID를 프로세스의 유효 그룹 ID 또는 보조 그룹 ID 중 하나로만 변경하는 것으로 제한됩니다.

시스템 chown()기능 - 이는 두 가지 모두에 의해 수행되는 문서화된 시스템 호출입니다.chown그리고chgrp쉘 유틸리티 -실패하도록 지정됨여러 가지 이유로. 그 중에는:

EACCES 경로 접두사의 구성 요소에 대한 검색 권한이 거부되었습니다.

ELOOP 경로 인수를 확인하는 동안 발견된 기호 링크에 루프가 있습니다.

EPERM 유효 사용자 ID가 파일 소유자와 일치하지 않거나 호출 프로세스에 적절한 권한이 없으며_POSIX_CHOWN_RESTRICTED해당 권한이 필요함을 나타냅니다.

그러나 루트가 아닌 사용자에게 권한 수정 권한을 부여하는 동작은 Solaris에만 국한된 것이 아닙니다. 있다매우 훌륭하다- 다소 오래된 경우 - Unix 파일 권한에 대한 내용은 다음과 같습니다.이 포럼 게시물저자는 다음과 같이 말합니다.

원래 유닉스에서는 파일 소유자가 파일을 다른 사람에게 양도하는 것을 허용했습니다. 파일 소유자는 소유자를 다른 사람으로 변경할 수 있습니다. 루트가 아닌 사용자가 이 작업을 취소할 수 있는 방법은 없었습니다... BSD[나중에]chown루트가 아닌 사용자에게서 제거됨...[일부 이유는]...사용자가 파일 시스템에서 가질 수 있는 디스크 공간의 양을 제한할 수 있는 디스크 할당량을 구현했습니다. 버릇없는 사용자는 할당량을 몰래 넘기기 위해 대용량 파일을 제공할 수 있습니다.

chown오늘날에는 루트가 아닌 사람 도 파일을 사용할 수 있는지 말하기가 쉽지 않습니다 . 많은 Unix 버전에서는 다음을 허용합니다.둘 다행동...

또 다른 좋은 - 그리고 더 최근의 -메일링 리스트 게시물이것을 인용하고 계속합니다.

대부분의 OS의 기본값은 chown루트로만 제한되는 것입니다. 그리고 보안을 고려하여 이 방식을 유지해야 한다는 합의가 있습니다. 루트가 아닌 사용자가 파일 소유자를 변경하고 실행 비트가 켜져 있는 경우 SUID및 SGID비트를 지워야 합니다. 이는 에서 발생할 수도 있고 발생하지 않을 수도 있습니다 root.

마지막 문단이 그 말을 잘 표현하고 있는 것 같아요.

해당 기사에는 CAP_CHOWNLinux에서 해당 기능을 제어하는 방법 도 언급되어 있습니다.(행동에만 영향을 주어야 함 POSIX_CHOWN_RESTRICTED). CAP_FOWNER동작이 약간 다른 기능 도 있습니다 .

그리고2003년에 당신이 지적한:

적어도 HPUX에서는 파일 소유자를 변경할 수 있습니다.( root예를 들어)권한이 있는 사용자가 아니더라도...

...구성 setprivgroup매개변수에 따라 달라집니다.

루트가 아닌 사용자가 파일 권한을 조작할 수 있는 경우에는 다음에서 언급한 것처럼 생각할 수 있습니다.이론적 해석귀하의 질문에 인용된 내용에 따르면, 사용자는 chown해당 사용자가 소유한 파일을 다른 사용자가 소유하게 될 수 있습니다. 파일의 그룹 소유권과 chowning 사용자의 그룹이 일치하지 않으면 사용자는 더 이상 해당 파일을 수정할 수 없습니다.

이 시나리오에서는chown 그 다음에 chgrp사용자가 더 이상 해당 파일의 권한을 변경할 권한이 없기 때문에 실패합니다 chown user:group.그룹사용자 자신의 것 중 하나입니다. 성공할 것입니다.

있다아마유사하게 발생할 수 있는 기타 여러 틈새 상황(예: 디렉토리 포함)어려운및/또는설정비트, 파일 시스템 및/또는 구현별 액세스 제어 목록.이 스레드예를 들어 흥미롭습니다. 셀 수 없이 많은 순열은 내 자신의 미약한 이해 범위를 훨씬 뛰어넘는 것입니다. 이것이 바로 이 답변이 위키에 있는 이유입니다. 이 글을 읽고 계시다면 개선할 가치가 있다고 믿으실 것이며, 방법도 알고 계시리라 믿습니다.제발.

-R또한 여기에서는 순환적 chown애플리케이션 과 관련하여 유사한 실패에 영향을 미칠 수 있는 파일 권한, 트리 순회 및 기호 링크의 다양한 효과에 대한 광범위한 문서도 있습니다 .

에서POSIX XRAT섹션 제목제삼그리고네 번째 도메인:

일반적으로 파일 계층 탐색 옵션을 지정하는 사용자는 단일 물리적 계층에서 작업하기를 원하므로 계층 외부의 파일을 참조할 수 있는 심볼릭 링크는 무시됩니다. 예를 들어, chown owner file은 -R 옵션이 지정된 동일한 명령과 다른 작업입니다. 이 예에서는 명령의 동작이 chown owner file설명되어 있지만 명령의 동작은 다음과 같습니다.chown -R소유자 파일은 세 번째와 네 번째 도메인에 설명되어 있습니다.

...논리적 보행을 기본값으로 설정하면 보안 문제가 있습니다. 역사적으로 명령은chown -R사용자 파일은 슈퍼유저에게 안전합니다.세트이드그리고설정파일의 소유권이 변경되면 비트가 손실되었습니다. 탐색이 논리적인 경우 사용자가 트리의 모든 파일을 가리키는 기호 링크를 삽입했을 수 있으므로 소유권 변경은 더 이상 안전하지 않습니다. 다시 말하지만, 이는 기호 링크를 통해 간접적으로 접근하지 않도록 계층 순회를 수행하는 명령에 옵션을 추가해야 하며 재귀 탐색을 수행하는 기록 스크립트는 즉시 보안 문제가 될 수 있습니다. 이는 대부분 시스템 관리자의 문제이지만 사용자 클래스에 따라 기본값을 다르게 설정하지 않는 것이 좋습니다.

...

4.3 BSD에서는 chgrp트리 순회 중에 대상이 아닌 기호 링크 그룹이 변경되었습니다. 4.4 BSD의 심볼릭 링크에는 소유자, 그룹, 모드 또는 기타 표준 UNIX 시스템 파일 속성이 없습니다.

그리고 POSIX에서chgrp페이지에 불완전한 재귀적 작업이 있을 수 있음을 가리키는 내용이 있습니다. -R또는 적어도 무엇을 의미합니까?사용된장차 ~ 가 되는:

System V와 BSD 버전은 서로 다른 종료 상태 코드를 사용합니다. 일부 구현에서는 종료 상태를 발생한 오류 수의 개수로 사용했습니다. 이 방법은 유효한 종료 상태 값의 범위를 오버플로할 수 있으므로 실행 불가능합니다. 표준 개발자는 종료 값으로 0과 >0만 지정하여 이를 마스크하기로 결정했습니다.

Question 2

가정 1: 성공 여부를 결정하는 규칙은 chown대상 사용자 및 그룹 부분을 독립적으로 확인합니다. 즉, 형식은 입니다 user_condition(target_uid, other_environment_parameters) && group_condition(target_gid, other_environment_parameters).

가정 2: chown(file, -1, -1)성공합니다.

가정 3: 성공 여부를 결정하는 규칙은 chown파일이 현재 속한 그룹에 따라 달라지지 않습니다.

결과: chown(file, uid, gid)성공한다면 성공할 것입니다 chown(file, -1, gid) && chown(file, uid, -1).

나는 이러한 가정을 위반하는 Unix 변형을 알지 못합니다. 꽤 안전한 것 같습니다.

ps이 문장은 위원회의 누군가가 얼마나 많은 옵션이 통화 제목에 들어갈 수 있는지에 대해 몇 시간 동안 토론한 후 피곤했을 때 말했거나 비서가 잘못 기록한 내용과 검토 중에 아무도 알아차리지 못한 것과 비슷합니다 . 결국 POSIX 이론적 근거에 인용된 성능 이유와 원자성(아, 소유권과 권한을 변경하기 위한 단일 호출만 있었다면)을 포함하여 사용자와 그룹이 자동으로 변경되도록 허용하는 다른 좋은 이유가 있습니다. ).

가정 3이 틀릴 수 있는 경우는 프로세스가 파일 소유자를 변경할 수 있는 기능을 얻을 수 있지만 파일에 대한 쓰기 권한이 있는 경우에만 시스템에 있습니다. 다소 현실적이긴 하지만, 이것이 해당되는 시스템이 있는지는 모르겠습니다. 그런 다음 chgrp루트나 파일을 소유한 사용자로 실행되지 않는 프로세스의 그룹으로 이동하면 나중에 chown.

재귀 호출의 경우 단일 패스가 성공했는데 전체 패스가 chgrp뒤따르는 전체 패스가 실패할 수 있는 극단적인 경우가 있습니다 . chown이는 소유자가 통과할 수 있는 권한이 없는 디렉터리를 포함하고 이러한 모든 경우로부터 보호하려는 응용 프로그램이 어쨌든 권한을 조정해야 하기 때문에 그다지 설득력 있는 주장은 아닙니다. 그럼에도 불구하고 이는 기술적으로 이러한 근거의 조건을 충족합니다. 실행 중인 프로세스에 유효 사용자 alice, 유효 그룹 staff및 파일 소유자를 임의로 변경할 수 있는 기능이 있다고 가정합니다(단순히 제공하기 위한 것이 아니라 루트가 아닌 프로세스에는 거의 부여되지 않지만 일부 유닉스 변형에는 이러한 기능이 있습니다).

$ ls -ld dir dir/file
d---rwx---  2 charlie  staff        1024 Apr  1  1970 dir
drw-rw----  2 charlie  staff          42 Apr  1  1970 file
$ chgrp -R students dir
$ chown -R bob dir
chown: dir: permission denied

Answer

가정 1: 성공 여부를 결정하는 규칙은 chown대상 사용자 및 그룹 부분을 독립적으로 확인합니다. 즉, 형식은 입니다 user_condition(target_uid, other_environment_parameters) && group_condition(target_gid, other_environment_parameters).

가정 2: chown(file, -1, -1)성공합니다.

가정 3: 성공 여부를 결정하는 규칙은 chown파일이 현재 속한 그룹에 따라 달라지지 않습니다.

결과: chown(file, uid, gid)성공한다면 성공할 것입니다 chown(file, -1, gid) && chown(file, uid, -1).

나는 이러한 가정을 위반하는 Unix 변형을 알지 못합니다. 꽤 안전한 것 같습니다.

ps이 문장은 위원회의 누군가가 얼마나 많은 옵션이 통화 제목에 들어갈 수 있는지에 대해 몇 시간 동안 토론한 후 피곤했을 때 말했거나 비서가 잘못 기록한 내용과 검토 중에 아무도 알아차리지 못한 것과 비슷합니다 . 결국 POSIX 이론적 근거에 인용된 성능 이유와 원자성(아, 소유권과 권한을 변경하기 위한 단일 호출만 있었다면)을 포함하여 사용자와 그룹이 자동으로 변경되도록 허용하는 다른 좋은 이유가 있습니다. ).

가정 3이 틀릴 수 있는 경우는 프로세스가 파일 소유자를 변경할 수 있는 기능을 얻을 수 있지만 파일에 대한 쓰기 권한이 있는 경우에만 시스템에 있습니다. 다소 현실적이긴 하지만, 이것이 해당되는 시스템이 있는지는 모르겠습니다. 그런 다음 chgrp루트나 파일을 소유한 사용자로 실행되지 않는 프로세스의 그룹으로 이동하면 나중에 chown.

재귀 호출의 경우 단일 패스가 성공했는데 전체 패스가 chgrp뒤따르는 전체 패스가 실패할 수 있는 극단적인 경우가 있습니다 . chown이는 소유자가 통과할 수 있는 권한이 없는 디렉터리를 포함하고 이러한 모든 경우로부터 보호하려는 응용 프로그램이 어쨌든 권한을 조정해야 하기 때문에 그다지 설득력 있는 주장은 아닙니다. 그럼에도 불구하고 이는 기술적으로 이러한 근거의 조건을 충족합니다. 실행 중인 프로세스에 유효 사용자 alice, 유효 그룹 staff및 파일 소유자를 임의로 변경할 수 있는 기능이 있다고 가정합니다(단순히 제공하기 위한 것이 아니라 루트가 아닌 프로세스에는 거의 부여되지 않지만 일부 유닉스 변형에는 이러한 기능이 있습니다).

$ ls -ld dir dir/file
d---rwx---  2 charlie  staff        1024 Apr  1  1970 dir
drw-rw----  2 charlie  staff          42 Apr  1  1970 file
$ chgrp -R students dir
$ chown -R bob dir
chown: dir: permission denied

chown(1) POSIX 사양에 대한 설명

답변1

답변2

관련 정보