첫 번째 답변의 일부를 기반으로이 질문:
파일에서 읽기(커널은 해당 파일에서 읽을 수 있는 권한이 있는지 확인한 다음 커널이 파일을 읽기 위해 디스크에 실제 명령을 수행해야 함)
파일에 대한 권한을 변경하려면 루트 권한이 필요합니다. 루트 권한이 있으면 사용자는 권한에 대한 걱정 없이 모든 파일에 액세스할 수 있습니다. 그렇다면 루트와 커널 사이에는 어떤 관계가 있습니까?
답변1
먼저 설명은 다음과 같습니다.
파일에 대한 권한을 변경하려면 루트 권한이 필요합니다.
에서남자 2 chmod다음과 같은 경우 chmod() 시스템 호출이 EPERM(권한 오류)을 반환하는 것을 볼 수 있습니다.
유효 UID가 파일 소유자와 일치하지 않으며 프로세스에 권한이 없습니다(Linux: CAP_FOWNER 기능이 없음).
이는 일반적으로 다음을 의미합니다.어느 하나파일의 소유자이거나 루트 사용자여야 합니다. 그러나 Linux의 상황은 좀 더 복잡할 수 있습니다.
그렇다면 루트와 커널 사이에는 어떤 관계가 있습니까?
인용한 텍스트에서 지적했듯이 커널은 시스템 호출을 수행하는 프로세스(즉, 실행 중인 사용자)의 UID가 요청한 작업을 수행할 수 있는지 확인하는 책임이 있습니다. 따라서 루트의 초능력은 루트 사용자(UID=0)가 요청한 작업을 항상 허용하도록 커널이 프로그래밍되었다는 사실에서 비롯됩니다.
Linux의 경우 발생하는 다양한 권한 확인의 대부분은 주어진 UID에 필요한 권한이 있는지 확인합니다.능력. 기능 시스템을 사용하면 누가 무엇을 할 수 있는지에 대해 보다 세밀하게 제어할 수 있습니다.
그러나 "루트" 사용자의 전통적인 UNIX 의미를 유지하기 위해 UID 0으로 실행되는 프로세스는 모든 기능을 갖습니다.
UID=0으로 실행되는 프로세스는 슈퍼유저 권한을 가지지만 여전히 시스템 호출 인터페이스를 통해 커널에 요청해야 합니다.
따라서 사용자 공간 프로세스는 루트로 실행되더라도 "사용자 모드" 그리고 커널은 "에서 실행 중입니다.커널 모드"는 실제로 CPU 자체에 대한 별개의 작동 모드입니다. 커널 모드에서 프로세스는 모든 메모리에 액세스하거나 모든 명령을 내릴 수 있습니다. 사용자 모드(x86 CPU에는 실제로 다양한 보호 모드가 있음)에서 프로세스는 액세스만 할 수 있습니다. 따라서 루트로 실행되는 사용자 공간 프로세스는 여전히 커널이 노출하는 커널 모드 기능에만 액세스할 수 있습니다.