Setuid

일부 프로그램은 호출자가 일반적으로 갖지 못하는 접근을 좁은 범위에서 통제하며 사용해야 합니다. 실행 가능한 일반 파일에서 set-user-ID 비트는 새 프로세스가 파일 소유자의 사용자 ID를 유효 사용자 ID로 받게 할 수 있습니다. 그러면 프로그램은 호출자 정보를 유지하면서 해당 신원에 허용된 작업을 수행할 수 있습니다.

Setuid는 “root로 실행”하라는 일반적인 지시가 아닙니다. 효과는 실행 파일의 소유자, 운영체제, 파일 시스템 및 마운트 옵션, 프로그램이 자격 증명을 관리하는 방식에 따라 달라집니다.

소유자 실행 위치의 소문자 s는 setuid와 소유자 실행이 모두 설정되었음을 뜻합니다. setuid는 있지만 소유자 실행이 없으면 ls -l은 그 위치에 대문자 S를 표시합니다.

모든 배포판이 같은 모드나 인증 설계를 사용한다고 가정하지 마세요. 예제에 의존하지 말고 실제 시스템을 확인합니다.

이 메커니즘은 신중하게 작성된 프로그램이 요청을 검증하고 보호된 상태에 제한된 변경을 수행하도록 할 수 있습니다. 예를 들어 로컬 비밀번호 변경 유틸리티는 일반 사용자가 직접 편집할 수 없는 인증 데이터에 통제된 접근이 필요할 수 있습니다. 현대 구현은 PAM, 파일 잠금, 정책 및 다른 보호 장치에도 의존하므로 setuid만으로 전체 작업 흐름을 설명할 수 없습니다.

8진수 표기에서 setuid는 선행 특수 비트 숫자에 4를 더합니다.

$ sudo chmod 4755 myfile

선행 4는 setuid를 설정하고 755는 일반 소유자, 그룹, 기타 사용자 비트를 설정합니다. 다른 모드를 바꾸지 않고 setuid를 제거하려면 chmod u-s myfile을 사용합니다.

Linux는 일반적으로 해석형 스크립트의 setuid를 적용하지 않습니다. 안전하게 처리하기 어려운 경쟁 조건과 인터프리터 관련 문제가 있기 때문입니다. nosuid로 마운트한 파일 시스템도 setuid와 setgid 효과를 억제합니다. 요구 사항에 맞으면 서비스 중개 작업, 신중하게 제한된 sudo 정책 또는 capabilities 같은 더 좁은 메커니즘을 선호하세요.

공유 시스템에서 임의의 쉘, 인터프리터 또는 복사한 프로그램에 실험으로 setuid를 추가하지 마세요. 기존 setuid 파일을 감사하고 격리된 일회용 환경에서만 연습합니다.