파일 권한에서 사용자 및 그룹 소유자의 우선 순위

나는 Linux (Arch Linux)의 파일 권한과 관련하여 예기치 않은 (나를 위해) 무언가를 만났다. 기본적으로 나는 가지고있다 :

• userX ...에서 groupX
• fileX userX:groupX ---rwx----

나를 어리둥절하게하는 것 :에 대한 작업 ( rwx)을 수행 할 수 없습니다 fileX. 이게 옳은 거니? 누군가 이것이 실제로 예상되는 행동인지 확인할 수 있습니까?

내가 수행 할 수있는 유일한 작업은 다음 mv과 rm나는 상위 디렉토리에 쓰기 권한이 있기 때문이다.

문제는 항상 가장 일반적인 권한 (기타-> 그룹-> 사용자)으로 시작하여 이러한 권한이 서로 축소되는 것으로 생각했습니다. 다시 말해, o=rwx누가 그룹과 사용자에 대한 권한이 무엇인지 신경 쓰는가? 분명히 이것은 사실이 아니지만 나에게는별로 의미가 없습니다. 직관적이지 않은 것 같습니다. 이 방법이 유용하게 보이는 유일한 방법은 매우 구체적인 사람 / 그룹을 쉽게 제외하는 것입니다. 게다가, 소유자 (그리고 그룹?)는 chmod어쨌든 옳을 수 있어야 하는가? 이 문제에 대한 의견이 있으십니까?

문제는 항상 가장 일반적인 권한 (기타-> 그룹-> 사용자)으로 시작하여 이러한 권한이 서로 축소되는 것으로 생각했습니다.

이 경우 "기타"권한이 모든 사람에게 적용됩니다.

다시 말해, o = rwx 인 경우 누가 그룹 및 사용자에 대한 권한을 관리합니까?

이전 문장과 다릅니다. 여기에서 userX가 파일을 소유하고 파일을 사용자가 읽을 수 있거나 userX가 속한 그룹이 파일을 소유하고 파일이 그룹 인 경우 userX에 읽기 권한이 있음을 의미합니다. -파일을 읽을 수 있거나 다른 파일을 읽을 수있는 경우 그러나 그것이 작동하는 방식이 아닙니다. 사실, o=rwx것을 의미 rwx권한을 다른 사람에게 적용되지만 그것은 다른 사람 아닌 실체에 대해 아무 말도하지 않습니다.

첫째, 사용자가 속한 그룹은 직접적으로 중요하지 않습니다. 커널에는 그룹에 속하는 사용자라는 개념이 없습니다. 커널이 유지 관리하는 것은 모든 프로세스에 대해 사용자 ID ( 유효한 UID ) 및 그룹 ID 목록 (유효한 GID 및 보충 GID)입니다. 그룹은 로그인 프로세스에 의해 로그인시 결정됩니다. 그룹 데이터베이스를 읽는 로그인 프로세스입니다 (예 :) /etc/group. 사용자 및 그룹 ID는 하위 프로세스 ¹에 의해 상속됩니다.

프로세스가 기존 Unix 권한으로 파일을 열려고 할 때 :

• 파일의 소유 사용자가 프로세스의 유효 UID 인 경우 사용자 권한 비트가 사용됩니다.
• 그렇지 않으면 파일의 소유 그룹이 프로세스의 유효 GID이거나 프로세스의 보조 그룹 ID 중 하나 인 경우 그룹 권한 비트가 사용됩니다.
• 그렇지 않으면 다른 권한 비트가 사용됩니다.

한 세트의 rwx 비트 만 사용됩니다. 사용자가 다른 그룹보다 우선하는 그룹보다 우선합니다. 존재하는 경우 액세스 제어리스트 알고리즘은 상기 일반화 설명했다

• 프로세스의 유효 UID에 대한 파일에 ACL이있는 경우 액세스 권한 부여 여부를 판별하는 데 사용됩니다.
• 그렇지 않으면, 프로세스의 유효 GID 또는 프로세스의 보충 그룹 ID 중 하나에 대한 파일에 ACL이 있으면 그룹 권한 비트가 사용됩니다.
• 그렇지 않으면 다른 권한 비트가 사용됩니다.

마스크의 영향을 포함하여 ACL 항목이 사용되는 방법에 대한 자세한 내용은 사용자가 여러 그룹 에 속하는 경우 ACLS 우선 순위를 참조하십시오 .

따라서 -rw----r-- alice internsAlice가 읽고 쓸 수 있고 인턴을 제외한 다른 모든 사용자가 읽을 수있는 파일을 나타냅니다. 권한과 소유권 ----rwx--- alice interns이있는 파일 은 Alice (인턴이든 아니든)를 제외한 인턴 만 액세스 할 수 있습니다. Alice가 전화 chmod를 걸어 권한을 변경할 수 있으므로 보안이 제공되지 않습니다. 엣지 케이스입니다. ACL이있는 시스템에서 일반화 된 메커니즘을 통해 특정 사용자 또는 특정 그룹에서 권한을 제거 할 수 있습니다.

각 동작 (읽기, 쓰기, 실행)에 대한 모든 비트를 정렬하지 않고 단일 비트 세트를 사용하면 몇 가지 장점이 있습니다.

• ACL이있는 시스템에서 사용자 또는 그룹 세트에서 권한을 제거 할 수있는 유용한 효과가 있습니다. ACL이없는 시스템에서는 한 그룹에서 권한을 제거 할 수 있습니다.
• 구현하는 것이 더 간단합니다. 여러 비트 세트를 결합하지 않고 하나의 비트 세트를 확인하십시오.
• 더 적은 수의 작업이 포함되므로 파일 권한을 분석하는 것이 더 간단합니다.

¹ _{setuid 또는 setgid 프로세스가 실행될 때 변경 될 수 있습니다 . 이것은 당면한 문제와 관련이 없습니다.}

보다 구체적인 권한은 덜 구체적인 권한보다 우선합니다.

groupX의 userX

fileX userX : groupX --- rwx ----

파일의 소유자이므로 소유자 권한 만 부여됩니다. 소유자에게 권한이 없습니다. 따라서 아무것도 할 수 없습니다. 파일의 소유자가 아니고 그룹 구성원 인 경우 그룹 권한이 적용됩니다.

위키 페이지의이 섹션을 읽으십시오

https://en.wikipedia.org/wiki/File_system_permissions#Classes

-rwxrw---- 소유자에게 읽기, 쓰기 및 실행 권한이 있고 그룹에 읽기 및 쓰기 권한이 있고 다른 사용자에게는 권한이 없음을 의미합니다.

제공 한 권한은 그룹 'groupX'에게 파일 읽기, 쓰기 및 실행 권한을 부여합니다. "groupX"그룹의 구성원이지만 파일의 소유자가 아닌 경우 이러한 권한이 적용됩니다.

이 경우 나는 당신이 실제로 파일의 소유자라고 가정합니다. 그러면 소유자에 대해 설정된 권한 만 귀하에게 적용됩니다. 물론 소유자는 파일에 대한 권한을 무시하거나 변경할 수 있습니다. 그러나 그룹은이를 수행 할 수 없습니다. 예를 들어, vim은 쓰기 권한이 없지만 소유자 인 파일에 쓰고 있는지 확인하라는 메시지를 표시합니다.

나는 보통 왼쪽에서 오른쪽으로 권한을 읽습니다. 내가 주인인가요? 그렇다면 소유자 권한이 적용됩니다. 그렇지 않다면; 나는 그룹의 회원입니까? 그렇다면 그룹 권한이 적용됩니다. 그렇지 않으면 "기타"권한이 적용됩니다.

어떤 경우에는 파일의 소유자이지만 쓰기 권한이없는 것이 유용합니다. 실수로 파일을 삭제하거나 수정하지 못하게합니다. 개인적으로 우연히 수정하지 않도록 모든 템플릿 파일에 400 권한을 설정했습니다. 실행 권한도 마찬가지입니다.

사용자를 그룹에 추가하고 그룹에 디렉토리 (070)에 대한 권한을 부여한 다음 다시 시작한 후 폴더에 액세스 할 수있었습니다.

그룹 만들기 : sudo groupadd groupname

그룹에 사용자 추가 : sudo gpasswd -a username groupname

전체 디렉토리가 올바른 그룹 소유권 아래에 있는지 확인하십시오 (수행 할 현재 그룹 이름의 구성원이어야 함). sudo chgrp -R groupname directory_path /

폴더에 rwx 그룹 만 제공하십시오 (rw 일 수 있으며 필요에 따라 조정 가능). sudo chmod -R 070 directory_path

위의 작업을 수행 한 후 로그 아웃했다가 다시 로그인하십시오. 그래도 작동하지 않으면 컴퓨터를 다시 시작하십시오. 이것을하는 것이 나를 위해 일했습니다.