Linux 권한 검사는 입력된 사용자 이름이 아니라 프로세스 자격 증명에 작동합니다. 프로세스에는 서로 관련되지만 역할이 다른 사용자 및 그룹 ID가 여러 개 있습니다. 대부분의 일반 프로그램은 일치하는 신원으로 시작하고 권한 프로그램은 서로 다른 값을 의도적으로 사용할 수 있습니다.
권한 · 레슨 7
프로세스 권한
실제, 유효, 저장 사용자 ID가 Linux 프로세스에서 호출자를 추적하고 권한을 관리하는 방식을 배웁니다.
실제 사용자 ID
실제 사용자 ID는 프로세스를 시작한 계정이나 그 조상 로그인 세션을 식별합니다. 프로그램은 이를 확인하여 호출자를 높은 유효 신원과 구분할 수 있습니다.
사용자 Bob이 시작한 일반 명령의 실제 사용자 ID는 보통 Bob의 UID와 같습니다. 다른 프로세스를 만든다고 그 자체로 새 계정이 생기거나 이 신원이 바뀌지는 않습니다.
프로세스의 실제 사용자 ID는 일반적으로 무엇을 식별하나요?
유효 사용자 ID
유효 사용자 ID는 여러 파일 시스템 및 권한 검사에 쓰이는 사용자 자격 증명입니다. 일반적으로 실제 UID와 일치합니다. 적용되는 setuid 프로그램을 실행하면 대신 실행 파일 소유자에서 초기화될 수 있습니다.
예를 들어 신중하게 설계된 비밀번호 유틸리티는 보호된 인증 데이터를 갱신하기 위해 높은 유효 UID로 실행될 수 있습니다. 프로그램은 여전히 호출자, 요청 계정, PAM 결과, 다른 문맥에 따라 정책을 적용해야 합니다. 유효 UID를 가졌다고 요청한 모든 작업이 자동으로 정당해지는 것은 아닙니다.
프로세스를 대신한 여러 접근 제어 결정에 사용되는 사용자 ID는 무엇인가요?
저장 Set-User-ID
저장 set-user-ID는 시스템 호출 규칙에 따라 프로그램이 나중에 복원할 수 있는 신원을 유지하게 합니다. 권한 프로그램은 유효 UID를 권한이 더 낮은 값으로 잠시 바꾸고 낮은 권한으로 일반 작업을 수행한 뒤 좁은 범위의 작업에만 저장 신원을 복원할 수 있습니다.
올바르게 구현하면 프로그램 전체에서 높은 권한을 유지하는 것보다 안전합니다. 더 이상 필요하지 않을 때 권한을 영구적으로 버리고 모든 자격 증명 변경 호출의 실패 여부를 확인해야 합니다.
권한 프로그램이 저장 set-user-ID를 유지할 수 있는 이유는 무엇인가요?
사용자 ID는 자격 증명 집합의 일부일 뿐
프로세스에는 실제, 유효, 저장, 보조 그룹 자격 증명도 있습니다. 파일 시스템 ID, capabilities, 네임스페이스, 보안 모듈, ACL, 마운트 옵션, 서비스 정책이 권한에 더 영향을 줄 수 있습니다. 따라서 “UID가 허용한다”는 설명은 완전한 설명의 일부일 때가 많습니다.
Linux에서는 ps와 /proc/PROCESS/status 같은 도구로 자격 증명을 확인합니다. 필드 제공 여부와 표시 형식이 다르므로 로컬 문서를 확인하고 공유 시스템에서 단순 실험을 위해 자격 증명을 바꾸지 마세요.
권한 전환이 없는 대부분의 일반 명령에서 실제 UID와 유효 UID는 어떻게 비교되나요?
레슨 완료
프로세스 권한 완료
이제 Linux 프로세스가 여러 사용자 신원을 가질 수 있는 이유를 설명할 수 있습니다.
실제 UID로 원래 호출자를 식별할 수 있습니다.
유효 UID를 활성 권한 검사와 연결할 수 있습니다.
저장 신원으로 통제된 권한 전환을 이해할 수 있습니다.
그룹 ID와 추가 보안 메커니즘을 전체 결정의 일부로 고려할 수 있습니다.