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


18

chown유틸리티에 대한 POSIX 스펙 은 구문 (이전의 ) (강조 광산) 에 대한 이론적 근거 섹션 에서 언급합니다 .chown user:groupchown user.group

이 POSIX.1-2008 볼륨에는 소유자와 그룹을 모두 지정하는 4.3 BSD 방법이 포함되어 있습니다.

  • chgrp 및 chown (사용자 ID 만 변경 한) 유틸리티를 사용하여 원하는 종료 조건을 달성 할 수없는 경우가 있습니다. 현재 소유자가 원하는 그룹의 구성원이 아니고 원하는 소유자가 현재 그룹의 구성원이 아닌 경우 소유자와 그룹이 동시에 변경되지 않으면 chown () 함수가 실패 할 수 있습니다.

나는 user:group구문이 편리한 것이라고 생각했다 . 위의 내용 chown user:group은 할 수없는 일이 있음을 의미합니다.chgrp group; chown user

이제 그 텍스트는 이해가되지 않습니다. 4.3BSD에서는 오직 root만이 소유자에게 파일을 변경할 수 있으므로 어떤 경우에도 그가 할 수있는 일에 제한이 없습니다.

SysV와 몇몇 다른 시스템은 파일 소유자가 파일의 사용자와 그룹을 다른 것으로 변경할 수 있도록 허용하거나 사용하도록 허용하지만 해당 시스템에서도 위의 텍스트는 의미가 없습니다. 좋아,을 수행하면 더 이상 파일의 소유자가 아니기 때문에 나중에 chown someone-else the-file할 수 chgrp something-else the-file는 없지만 chgrp첫 번째 (파일 소유자 유지) 를 수행하는 데 방해 chown가되지는 않습니다. 위의 텍스트는 정확히 말하고 있습니다.

본인 및 원하는 소유자가 현재 그룹의 구성원 이 아닌 문제를 이해하지 못합니다 .

따라서 소유자와 그룹이 동시에 변경되지 않으면 chown () 함수가 실패 할 수 있는 조건은 무엇입니까?


1
@Robert, 그 규칙은 어떤 시스템에 적용됩니까? 내가 아는 시스템에서, 당신은 루트이고 당신은 당신이 좋아하거나 user1이 아닌 것을 할 수 있고 아무것도 할 수 없습니다. 시스템에 따라 user1 인 경우 어쨌든 소유자를 변경할 수 없거나 가능할 때 그룹을 원하는 것으로 변경 한 다음 사용자를 원하는대로 변경할 수 있습니다.
Stéphane Chazelas 2016 년

내가 소유 한 디렉토리, 다른 사람이 소유 한 파일 및 내가 속해있는 그룹에있는 경우 다른 권한으로 인해 읽을 수 있습니다. 그런 다음 본인을 소유자로 만들기 위해 복사 할 수 있으며 새 그룹 (내 회원)이 있습니다. 따라서 chown me:my-group file파일이 읽기 / 쓰기 액세스 권한이있는 위치 (고정 없음)에있는 경우 루트가 아닌 것으로 허용하려면 OS에 저장해야합니다 . 먼저 소유자가 아닌 것으로 chgrp 할 수 없었습니다. 내가 만들 수없는 파일이 생성되므로 먼저 chown 할 수 없었습니다. 내가 회원이 아닌 그룹의 파일을 소유하고 있습니다.
ctrl-alt-delor

@richard, 아니 안전 하지 않습니다 . 해당 파일은 액세스 권한이없는 다른 디렉토리에 하드 링크 될 수 있습니다. 소유하지 않은 파일 (예 : 기본적으로 Linux)을 연결할 수있는 시스템에서는 파일에 대한 쓰기 권한이있는 디렉토리에 파일을 연결하여 소유권을 주장 할 수 있습니다.
Stéphane Chazelas

이 텍스트를 찾았는데 왜 내가 틀렸는 지 설명합니다 (안전하지는 않습니다).“파일을 적절하게 허용하면 보안상의 허점이 될 것입니다. 예를 들어, 누군가 누군가 파일을 연 다음 열린 파일 핸들에서 fstat를 호출하여 소유권과 권한을 확인하고 누군가 실행중인 프로그램 만이 데이터를 생성 할 수 있다고 결론을 내릴 수 있습니다. 파일을 적절하게 만들 수 있다면 다른 사람이 원하는대로 파일 내용을 변경할 수 있습니다.”— unix.stackexchange.com/questions/68439/…
ctrl-alt-delor

답변:


5

마이크로 소프트는 Interix 유닉스 서브 시스템 (은퇴) 는 NT 커널을위한 몇 가지 다른 사람보다 사용자 및 그룹 권한을 조금 다르게 처리 :

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

더 구체적인 수동 발췌문 은 다음과 같습니다 .

Windows에서 사용자 또는 그룹은 오브젝트를 소유 할 수 있습니다. 이것은 사용자 만 객체를 소유하는 UNIX와 다릅니다.

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

개체에 대한 액세스 권한이있는 사용자 및 그룹은 해당 SID로 식별됩니다. Windows로 보안 할 수있는 모든 개체에는 DACL (임의 액세스 제어 목록)이 있으며 ACE (액세스 제어 항목)라는 별도의 항목으로 구성됩니다. ACE에는 두 가지 중요한 정보, 즉 사용자 또는 그룹 SID와 개별 사용자 또는 그룹이 개체에 얼마나 많이 액세스하는지에 대한 설명이 포함됩니다.

CHGRP

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

추신

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

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

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

내가 읽었을 때 사용자 계정이 해당 그룹이 소유 한 파일의 권한을 수정할 수있는 충분한 권한을 가진 Windows 그룹에 속하는 경우 chgrp사용자 계정이 제어 할 수없는 외부에서 해당 파일 을 효과적으로 작성할 수 있습니다. 이것은 당신이 가지고 chown있고 명시 적 user:group매개 변수 보다 제어가 적습니다 . 선언의 가능성이없는 그 맥락에서 user: :group 는 달리 같은 결과를 얻을 수 없었다 않았다.

다음은 Interix가 Windows ACL과 상호 작용하는 방법에 대한 자세한 내용 의 링크입니다. 이러한 지식이 다른 Unix 변형의 Samba 파일 시스템에 어떻게 적용되는지에 중점을 둡니다.

다음은 튜너 블 을 설명 하는 현재 사용되지 않는 Solaris 문서에 대한 링크rstchown 입니다.

chown(2)시스템 호출에 대한 POSIX 시맨틱이 적용되는지 여부를 나타냅니다 .

분명히 매개 변수가 0... 의 값으로 설정된 경우

POSIX 시맨틱을 끄면 다양한 보안 취약점이 생길 수 있습니다. 또한 사용자가 파일의 소유권을 다른 사용자에게 변경 하고 사용자 또는 시스템 관리자의 개입없이 파일을 다시 검색 할 수없는 가능성을 엽니 다 .

이러한 옵션은 Solaris의 POSIX 적합성을 무효화하지 않습니다 . 단지 옵션이라는 것만으로도이를 준수 하는 것으로 간주합니다 .

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

다음의 기호 상수는 -1 이외의 값으로 정의해야합니다. 상수 값은 0으로 정의되는 경우, 어플리케이션을 사용한다 sysconf(), pathconf()또는 fpathconf()기능, 또는 getconf시간이나 문제의 특정 경로에 대한 시스템에 존재하는 기능을 결정하기 위해, 유틸리티.

_POSIX_CHOWN_RESTRICTED

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

chown()시스템 기능 - 모두에 의해 문서화 된 시스템 호출입니다 chownchgrp쉘 유틸리티 -됩니다 실패 지정된 수많은 이유. 그들 중 :

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

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

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

그러나 루트가 아닌 사용자에게 권한 수정 권한을 부여하는 동작은 Solaris에서만 고유 한 적이 없습니다. 이 매우 우수 - 약간 일 경우 -에서 유닉스 파일 권한의 범위 이 포럼 게시물이 있는 저자 상태 :

원래 Unix에서는 파일 소유자가 파일을 제공 할 수있었습니다. 파일 소유자가 소유자를 다른 사람으로 변경할 수 있습니다. 이 작업을 취소 할 루트가 아닌 사용자에 대한 방법이 없었다 ... BSD는 [이후] 제거 chown루트가 아닌 사용자로부터 ... [때문에 부분적] 는 디스크 할당량을 구현 제한 할 수있는 디스크 공간 파일 시스템에 사용자가있을 수 있습니다 ... 나쁜 사용자는 할당량을 초과하여 큰 파일을 제공 할 수 있습니다.

오늘날에는 루트가 아닌 chown파일이 파일 인지 판단하기가 쉽지 않습니다 . 많은 버전의 유닉스는 두 가지 행동을 모두 허용 합니다 ...

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

대부분의 OS에서 기본값은 chown루트로만 제한됩니다. 그리고 보안 고려를 위해이 방식을 유지해야한다는 합의가 있습니다. 루트가 아닌 사용자가 파일의 소유자를 변경하고 실행 비트가 켜져 있으면 SUIDSGID비트를 지워야합니다. 이 발생하거나 발생하지 않을 수 있습니다 root.

나는 마지막 문단이 멋지게 말합니다.

이 기사는 CAP_CHOWNLinux에서 해당 기능을 제어하는 ​​것에 대한 참조도 제공 합니다 ( POSIX_CHOWN_RESTRICTED동작 에만 영향을 미침 ) . 또한 CAP_FOWNER기능에는 약간의 차이가 있습니다.

그리고 2003 년에 지적한 대로 :

최소한 HPUX에서는 권한이없는 사용자라도 파일 소유자를 변경할 수 있습니다 ( root예 : 등) .

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

루트가 아닌 사용자가 파일 권한을 조작 할 수있는 경우, 귀하의 질문에 인용 된 이론적 근거 에서 언급 한 바와 같이 , chown사용자는 다른 사용자가 소유하도록 해당 사용자가 소유 한 파일을 사용자가 가질 수 있습니다 . 파일의 그룹 소유권과 chowning 사용자의 그룹이 정렬되지 않으면 사용자는 더 이상 해당 파일을 수정할 수 없습니다.

이 시나리오에서는 chown 다음 chgrp 반면에, 더 이상 파일의 권한을 변경할 수있는 권한이 없을 것이다 사용자로 실패 chown user:group너무 오래 같이 - 그룹 중 하나입니다 사용자 자신이 - 성공하는 것입니다.

있습니다 아마도 디렉토리 포함 할 수 있습니다 유사하게 발생할 수있는 수많은 다른 틈새 시장 상황, 끈적 및 / 또는 setgid를 비트 파일 시스템 및 / 또는 구현 고유의 액세스 제어 목록. 예를 들어이 스레드 는 재미 있습니다. 셀 수없이 많은 순열이 내 자신의 미약 한 이해를 훨씬 뛰어 넘기 때문에이 답변에 위키가 있습니다. 당신이이 글을 읽고 있다면, 당신은 가치 개선 믿고, 당신은 당신이 방법을 알고 생각 - 해 주시기 바랍니다 .

관련하여 유사한 실패에 영향을 수있는 파일 권한, 트리 탐색 및 심볼릭 링크의 다양한 미칠 수있는 영향에 대한 광범위한 문서도있다 -Recursive chown여기 응용 프로그램 :

에서 POSIX XRAT의 섹션 머리글 세 번째네 번째 도메인 :

일반적으로 파일 계층 구조 순회 옵션을 지정하는 사용자는 단일 물리적 계층 구조에서 작동하기를 원하므로 계층 외부의 파일을 참조 할 수있는 기호 링크는 무시됩니다. 예를 들어 chown owner 파일은 -R 옵션이 지정된 동일한 명령과 다른 작업입니다. 이 예에서는 명령 동작에 chown owner file대해 설명하고 명령 chown -R소유자 파일 의 동작은 세 번째 및 네 번째 도메인에 설명합니다.

... 논리적 걷기를 기본값으로하는 보안 문제가 있습니다. 과거에는 chown -R파일 의 소유권이 변경 될 때 setuidsetgid 비트가 손실 되었기 때문에 명령 사용자 파일이 수퍼 유저에게 안전했습니다 . 워크가 논리적 인 경우 사용자가 트리의 파일을 가리키는 심볼릭 링크를 삽입했을 수 있으므로 소유권 변경이 더 이상 안전하지 않습니다. 다시 말하지만, 심볼릭 링크를 통해 간접적이지 않기 위해 계층 구조 통과 명령에 옵션을 추가해야하며 재귀 보행을 수행하는 기록 스크립트는 즉시 보안 문제가됩니다. 이것은 대부분 시스템 관리자에게 문제가되지만 다른 클래스의 사용자에 대해 다른 기본값을 사용하지 않는 것이 좋습니다.

...

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

그리고 POSIX의에서 chgrp페이지 적절한이 가능한 불완전한에있는 포인트가 -Recursive 행동, 또는 적어도 무엇을 사용 수 :

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


1
@StephaneChazelas-이해하게 된 것을 기쁘게 생각합니다. ∆that∆는 전체 권한에 특히 좋지 않기 때문에-특히 SE 속성이 관련되어 있기 때문에 일종의 혼란입니다. 연결이 느슨합니다-링크! 문제가 발생하면 두 개의 -R 조치가 발생할 수 있습니다. 당신이 말한 것처럼 사용자와 그룹 모두에 발을 들여 놓으면 아무 것도 깨지 않을 것입니다. 실제로 내 장점은 아닙니다. 죄송합니다.
mikeserv

1
좋은 지적, 나는 -R을 생각하지 않았다. chgrp에서 디렉토리에 대한 검색 또는 읽기 액세스를 느슨하게 할 수있는 이미지를 만들 수 있습니다. 그러면 파일의 권한을 변경하지 못하게되지만 소유권이나 권한을 처리하는 전통적인 Unix 방법으로 다시 볼 수 없습니다. 일어날 수 있도록. 조사 할 가치가있는 다른 영역은이를 지원하는 시스템의 NFSv4 ACL 일 것입니다 (Solaris, FreeBSD, SUSE ...)
Stéphane Chazelas

@ StéphaneChazelas-이 게시물이 답변하지 않는 귀하의 질문의 측면이 있습니까?
mikeserv 2016 년

그 철저한 연구에 감사드립니다. POSIX 텍스트가 적용되는 NT Unix 하위 시스템으로 예제를 추가 할 수 있다면 좋을 것입니다. 바운티가 커뮤니티 위키 답변과 어떻게 작동하는지 잘 모르겠습니다. 시도해 볼게요.
Stéphane Chazelas

@ StéphaneChazelas-나는 포인트를 신경 쓰지 않았으며 결코 보지 못했습니다. 나는 그것을 망치지 않기를 바랐다. 나는 그것이 좋은 부분이 될 것이라고 생각 하지는 않습니다-NT Unix 4를 의미합니까? 마이크로 소프트의 공식 문서는 적어도 여전히 Interix 일 때 POSIX 규정 준수를 주장하며, 조금 이상하게 chgrp chown
말하지만

1

가정 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).

나는 이러한 가정 중 하나를 위반하는 유닉스 변형을 모른다. 꽤 안전 해 보인다.

이 문장은위원회의 누군가가 몇 번의 옵션에 대한 논의 끝에 지쳤을 때 전화를받을 수 있는가, 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

POSIX는 유닉스에만 국한된 것이 아닙니다. POSIX 하위 시스템 / API (예 : Microsoft Windows NT)가있는 많은 비 유닉스 OS가 있습니다. 나는 그러한 조건이 그 결과를 주장하기에 충분하지 않다. chgrp또는 chown다른 일을 할 수있는 능력에 영향을주는 부작용이있을 수 있습니다. 예를 들어 chown의 기능을 제거하면 chgrp사실입니다. chgrpsetuid를 / setgid를 비트, 그것은 ACL 또는 보안 컨텍스트의 다른 형태의 어떤 형태의 ... 취소 할 수 있습니다 클리어
스테판 Chazelas가

@ StéphaneChazelas 우리는 그 chown다음에 chgrp실패 할 수 있다는 데 동의 하지만 질문은에 관한 chgrpchown입니다. 흠, 보안 컨텍스트 .. 아마도 액세스 제어가 필수 인 시스템 chgrp에서 파일을 더럽 히고 더 이상 chownable하지 못하게 할 수 있습니까? 그것은 멀리 가져온 것 같습니다.
Gilles 'SO- 악 그만해'

멀리 가져 오지 않았을 수도 있습니다. NFSv4 / WinNT ACL에 대해서는 잘 모르지만 이런 종류의 일이 일어날 수있는 (또는 세 번째 가정을 무효화 할 수있는) 무언가가 있다고 생각합니다. 그럼에도 불구하고 그 글은 매우 구체적이며 글을 쓴 사람은 누구나 구체적으로 본을 보일 것입니다. 어쩌면 일부 Microsoft 사람들이 작성한 것일 수도 있습니다.
Stéphane Chazelas

최신 수정 사항을 다시 작성하십시오. chown -R bob : students를 사용하는 alice는에 대한 검색 권한을 여전히 잃어 버렸 dir으므로 작동 chown하려면 파일 깊이를 먼저 처리해야하며 구현이 무엇인지 모릅니다. chmodp : chown이 chmod u : g가 할 수 없었던 곳에서 실패 할 수있는 거의 유효한 경우입니다. 그러나 그것은 이론적 근거와 실제로 합쳐지지는 않습니다.
Stéphane Chazelas

재검토되지 않은 비서의 잘못된 설명과 최첨단 재귀 chown이론은 상충되는 것으로 보인다.
mikeserv 2016 년
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.