Linux(Arch Linux)의 파일 권한과 관련하여 예상치 못한 문제가 발생했습니다. 기본적으로 나는 다음을 가지고 있습니다 :
userX존재하다groupXfileX userX:groupX ---rwx----
나를 혼란스럽게 하는 것은 이것이다: 나는 ( rwx) 로 아무것도 할 수 없다는 것이다 fileX. 이 올바른지? 이것이 실제로 예상되는 동작인지 확인할 수 있는 사람이 있나요?
내가 할 수 있는 유일한 일은 상위 디렉터리에 대한 쓰기 권한이 있기 mv때문입니다 .rm
문제는 이러한 권한이 가장 일반적인 권한(기타 -> 그룹 -> 사용자)부터 시작하여 서로 중복된다고 항상 생각해왔다는 것입니다. 즉, o=rwx그룹과 사용자의 권한이 무엇인지 누가 신경 쓰나요? 분명히 그렇지는 않지만 나에게는 그다지 이해가 되지 않는 것 같습니다. 이 접근 방식이 유용해 보이는 유일한 곳은 매우 구체적인 사람/그룹을 쉽게 제외하는 것인데, 이는 현명한 접근 방식(IMHO)처럼 보이지 않습니다. 게다가 소유자(그리고 그룹?)도 그럴 수 있어야겠죠 chmod? 이것에 대한 생각이 있나요?
답변1
문제는 이러한 권한이 가장 일반적인 권한(기타 -> 그룹 -> 사용자)부터 시작하여 서로 중복된다고 항상 생각해왔다는 것입니다.
그렇다면 "기타" 권한이 모든 사람에게 적용됩니다.
즉, 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이 파일에 존재하는 경우 그룹 권한 비트가 사용됩니다.
- 그렇지 않으면 다른 권한 비트를 사용하십시오.
당신은 또한 볼 수 있습니다사용자가 여러 그룹에 속하는 경우 ACLS 우선순위마스킹 효과를 포함하여 ACL 항목을 사용하는 방법에 대한 자세한 내용입니다.
따라서 -rw----r-- alice internsAlice가 읽고 쓸 수 있고 인턴을 제외한 다른 모든 사용자가 읽을 수 있는 파일을 나타냅니다. 권한과 소유권이 있는 파일은 ----rwx--- alice internsAlice를 제외한 인턴만 액세스할 수 있습니다(인턴인지 여부에 관계 없음). Alice는 권한 변경을 위해 호출할 수 있으므로 chmod이는 보안을 제공하지 않습니다. ACL이 있는 시스템에서는 공통 메커니즘을 통해 특정 사용자 또는 특정 그룹에서 권한을 제거할 수 있으며 이는 때때로 유용합니다.
각 작업(읽기, 쓰기, 실행)에 대해 비트 집합을 모두 OR하는 대신 비트 집합을 사용하면 다음과 같은 장점이 있습니다.
- ACL이 있는 시스템의 사용자 또는 그룹 집합에서 권한을 제거할 수 있도록 하는 유용한 효과가 있습니다. ACL이 없는 시스템에서는 그룹에서 권한을 제거할 수 있습니다.
- 구현하는 것이 더 간단합니다. 비트 세트를 함께 결합하는 대신 비트 세트를 확인하십시오.
- 관련된 작업이 적기 때문에 파일 권한을 분석하는 것이 더 간단합니다.
1다음 과 같은 경우 변경될 수 있습니다.설정값또는 setgid 프로세스가 실행됩니다. 이는 당면한 문제와 관련이 없습니다.
답변2
보다 구체적인 권한이 덜 구체적인 권한보다 우선합니다.
그룹의 사용자 X
파일X 사용자X:그룹X ---rwx----
귀하는 파일의 소유자이므로 소유자 권한만 부여됩니다. 소유자에게 권한이 없습니다. 그러므로 당신이 할 수 있는 일은 아무것도 없습니다. 파일의 소유자가 아니고 그룹 구성원이 아닌 경우에는 그룹 권한이 적용됩니다.
위키 페이지의 이 부분을 읽어보세요.
https://en.wikipedia.org/wiki/File_system_permissions#Classes
답변3
-rwxrw----이는 소유자가 읽기, 쓰기 및 실행 권한을 가지고 있고, 그가 속한 그룹은 읽기 및 쓰기 권한을 가지며, 다른 그룹은 권한이 없음을 의미합니다.
제공한 권한은 파일을 읽고, 쓰고, 실행할 수 있는 "groupX" 권한을 그룹에 부여합니다. 귀하가 "groupX" 그룹의 구성원이지만 파일의 소유자가 아닌 경우 이러한 권한이 귀하에게 적용됩니다.
이 경우에는 귀하가 실제로 파일의 소유자라고 가정합니다. 소유자에게 설정된 권한만 귀하에게 적용됩니다. 물론 소유자는 파일의 권한을 재정의하거나 변경할 수 있습니다. 그러나 그룹은 이를 수행할 수 없었습니다. 예를 들어, vim은 쓰기 권한은 없지만 소유자에게 속한 파일에 쓰고 있는지 확인하라는 메시지를 표시합니다.
저는 보통 왼쪽에서 오른쪽으로 권한을 읽습니다. 내가 주인인가? 그렇다면 소유자 권한이 적용됩니다. 그렇지 않다면 나는 그룹의 구성원입니까? 그렇다면 그룹 권한이 적용됩니다. 그렇지 않은 경우 "기타"에 대한 권한이 나에게 적용됩니다.
어떤 경우에는 파일의 소유자이지만 쓰기 권한이 없는 것이 유용할 수 있습니다. 실수로 파일을 삭제하거나 수정하는 것을 방지합니다. 개인적으로 저는 실수로 파일을 수정하지 않도록 하기 위해 모든 템플릿 파일에 대해 권한 400을 설정했습니다. 실행 권한도 마찬가지입니다.
답변4
사용자를 그룹에 추가하고 디렉터리(070)에 대한 그룹 권한을 부여한 다음 재부팅 후 폴더에 액세스할 수 있었습니다.
그룹 만들기:sudo 그룹그룹 이름 추가
그룹에 사용자 추가:sudo gpasswd -a 사용자 이름그룹 이름
전체 디렉토리가 올바른 그룹 소유권 아래 있는지 확인하십시오(실행하려면 그룹 이름의 현재 구성원이어야 함).sudo chgrp -R 그룹 이름 디렉터리 경로/
폴더의 그룹 rwx만 제공합니다(단지 rw일 수도 있으며 필요에 따라 조정).sudo chmod -R 070 디렉토리 경로
위 사항을 모두 완료하신 후 반드시 로그아웃 후 다시 로그인 하시기 바랍니다. 그래도 문제가 해결되지 않으면 컴퓨터를 다시 시작하세요. 이렇게 하면 나에게 효과적이다.