유닉스-계열 운영 시스템은 종종 user ID 또는 UID로 약칭되는 user identifier라는 값에 의해 사용자를 식별합니다. UID는, 그룹 식별자 (GID)와 기타 접근 제어 기준과 함께, 사용자가 접근할 수 있는 시스템 자원을 결정하기 위해 사용됩니다. 암호 파일은 텍스트 사용자 이름을 UID에 매핑합니다. UID는 유닉스 파일 시스템의 inode, 실행 중인 프로세스, 타르 아카이브 및 현재-퇴화된 네트워크 정보 서비스에 저장됩니다. POSIX-호환 환경에서, 명령줄 명령 id는 현재 사용자의 UID와 마찬가지로 사용자 이름, 주요 사용자 그룹과 그룹 식별자 (GID)와 같은 추가 정보를 제공합니다.
Process attributes
POSIX 표준은 특권을 가진 프로세스에게 다른 역할을 동적으로 수행할 수 있도록 프로세스 설명자 테이블에 세 가지 다른 UID 필드를 도입했습니다.
Effective user ID
프로세스의 유효 UID (euid)는 대부분의 접근 검사에 사용됩니다. 그것은 역시 해당 프로세스에 의해 생성된 파일에 대해 소유자로 사용됩니다. 프로세스의 유효 GID (egid)는 역시 접근 제어에 영향을 미치고 사용 중인 특정 커널 구현의 의미와 사용된 마운트 옵션에 따라 파일 생성에도 영향을 미칠 수 있습니다. BSD 유닉스 의미론에 따르면, 새로 생성된 파일에 부여된 그룹 소유권은 파일이 생성된 디렉토리의 그룹 소유권에서 무조건 상속됩니다. AT&T 유닉스 시스템 V 의미 체계에 따르면 (리눅스 변형에서도 채택됨), 새로 생성된 파일은 통상적으로 파일을 생성하는 프로세스의 egid에 의해 지정된 그룹 소유권을 제공합니다. 대부분의 파일시스템은 새로 생성된 파일의 그룹 소유권과 관련하여 BSD 또는 AT&T 의미 체계를 사용해야 하는지 여부를 선택하는 방법을 구현합니다; BSD 의미 체계는 S_ISGID (s-gid) 허가권이 설정될 때 특정 디렉토리에 대해 선택됩니다.
File system user ID
리눅스는 역시 파일 시스템에 대한 접근 제어에 명시적으로 사용되는 파일 시스템 사용자 ID (fsuid)를 가집니다. 그것은 명시적으로 달리 설정하지 않는 한 euid와 일치합니다. 그것은 ruid, suid, 또는 euid가 root이면 오직 root의 사용자 ID일 수 있습니다. euid가 변경될 때마다, 변경 사항이 fsuid로 전파됩니다.
fsuid의 의도는 프로그램 (예를 들어, NFS 서버)에게 신호를 보내기 위한 해당 uid 허가권을 부여 없이 일부 주어진 uid의 파일 시스템 권한으로 자신을 제한하도록 허용하는 것입니다. 커널 2.0 이후로, 리눅스는 신호 전송에 대한 SUSv3 규칙을 준수하기 때문에 fsuid의 존재는 더 이상 필요하지 않지만, fsuid는 호환성 이유로 남아 있습니다.
Saved user ID
저장된 사용자 ID (suid)는 상승된 권한으로 실행되는 프로그램이 일시적으로 권한이 없는 작업을 수행해야 할 때 사용됩니다; euid를 특권 값 (전형적으로 0)에서 일부 특권 없는 값 (특권 값 이외의 다른 값)으로 변경하면 특권 값을 suid에 저장되도록 하는 원인이 됩니다. 나중에, 프로그램의 euid는 상승된 권한이 복원될 수 있도록 suid에 저장된 값으로 다시 설정될 수 있습니다; 권한 없는 프로세스는 euid를 ruid 값, suid 값, 또는 euid 값의 세 가지 값 중 하나로 설정할 수 있습니다.
Real user ID
실제 UID (ruid) 및 실제 GID (rgid)는 프로세스의 실제 소유자를 식별하고 신호 전송 권한에 영향을 줍니다. 수퍼유저 권한 없는 프로세스는 발신자의 ruid 또는 euid가 수신자의 ruid 또는 suid와 일치하면 오직 또 다른 프로세스에 신호를 보낼 수 있습니다. 자식 프로세스는 부모로부터 자격 증명을 상속하기 때문에, 자식과 부모는 서로 신호를 보낼 수 있습니다.
Conventions
Type
POSIX는 UID를 정수 유형이 되도록 요구합니다. 대부분의 유닉스-계열 운영 시스템은 UID를 부호 없는 정수로 나타냅니다. UID 값의 크기는 시스템마다 다릅니다; 일부 유닉스 OS는 15비트 값을 사용하며, 최대 32767 값을 허용하지만, 리눅스 (버전 2.4 이전)와 같은 다른 OS는 16비트 UID를 지원하며, 가능한 65536개의 고유한 ID를 만듭니다. 대부분의 현대 유닉스-계열 시스템 (예를 들어, 1990년 솔라리스-2.0, 2001년 리눅스 2.4)은 4,294,967,296 (232)개의 고유 ID를 허용하는 32비트 UID로 전환했습니다.
Reserved ranges
리눅스 표준 기본 핵심 사양은 0에서 99 사이의 UID 값이 시스템에 의해 정적으로 할당되어야 하고, 응용 프로그램에 의해 생성되어서는 안 된다고 지정하지만, 100에서 499 사이의 UID는 시스템 관리자에 의해 동적 할당 및 설치 스크립트 후반부에 할당하도록 예약되어야 합니다.
데비안 리눅스는 동적으로 할당된 시스템 사용자와 그룹에 대해 100–999 범위를 예약할 뿐만 아니라, 60000–64999 범위의 사용자와 그룹을 중앙에서 정적으로 할당하고 65000–65533 범위를 추가로 예약합니다.
Systemd는 다음을 포함한 여러 특수 UID 범위를 정의합니다:
- 60001-60513: systemd-homed에서 관리하는 홈 디렉토리에 대해 UID
- 61184-65519 (0xef00-0xffef): 동적 사용자에 대해 UID
FreeBSD에서 패키지에 대한 UID가 필요한 포터는 50에서 999 사이에서 자유롭게 선택하고 그런-다음 정적 할당을 등록할 수 있습니다.
일부 POSIX 시스템은 500 (macOS, Red Hat Enterprise Linux 버전 6까지)부터 새로운 사용자에게 UID를 할당하고, 다른 시스템은 1000부터 시작합니다 (Red Hat Enterprise Linux 버전 7, openSUSE, Debian). 많은 리눅스 시스템에서, 이들 범위는 useradd와 유사한 도구에 대해 /etc/login.defs에 지정됩니다.
엔터프라이즈 네트워크 (예를 들어, LDAP 및 NFS 서버를 통한)에서 중앙 UID 할당은 클라이언트 컴퓨터에 지역적으로 할당된 UID와의 잠재적인 충돌을 피하기 위해, 1000보다 훨씬 크고 60000–65535 범위를 벗어나는 UID 번호만 사용하도록 제한될 수 있습니다.
OS-수준 가상화는 예를 들어 리눅스 이름공간을 사용하여 사용자 식별자를 다시 매핑할 수 있고, 따라서 다시 매핑된 UID 및 GID가 매핑되는 범위를 할당해야 합니다:
- snapd는 UID와 GID를 524288-589823 (0x80000-0x8ffff) 범위로 매핑합니다.
- systemd-nspawn 컨테이너별 UID 범위 자동 할당은 524288-1879048191 (0x80000-0x6fffffff) 범위를 사용합니다.
The systemd authors recommend that OS-level virtualization systems should allocate 65536 (216) UIDs per container, and map them by adding an integer multiple of 216.
Special values
- 0: 수퍼유저는 통상적으로 영 (0)의 UID를 가집니다.
- −1: 값 (uid_t) -1는 생략된 인수를 식별하기 위해 POSIX에 의해 예약됩니다.
- 65535: 이 값은 uid_t가 16비트일 때 API 오류 반환 값이기 때문에 여전히 피합니다.
- Nobody: 역사적으로, OpenBSD에 의한 것처럼 215−1 = 32,767과 같은 다른 값도 사용 중이지만, 사용자 "nobody"는 여러 운영 시스템에 의해 UID -2를 할당되었습니다. 16비트와 32비트 UID 사이의 호환성을 위해, 많은 리눅스 배포판은 이제 그것을 216−2 = 65,534가 되도록 설정합니다; 리눅스 커널은 기본적으로 32비트 UID가 16비트 시스템 호출의 반환 값에 맞지 않을 때 이 값을 반환합니다. 페도라 리눅스는 시스템 사용을 위해 정적으로 할당된 범위 (0-99)의 마지막 UID를 nobody: 99에 할당하고, nfsnobody 대신 65534를 호출합니다.
Alternatives
NFSv4는 정수가 아닌 텍스트 "user@domain" 이름을 사용하여 프로토콜 패킷에서 사용자 (및 그룹)를 식별함으로써 숫자 식별자 충돌을 방지하기 위해 의도된 것입니다. 어쨌든, 운영-시스템 커널과 로컬 파일 시스템이 정수 사용자 식별자를 계속 사용하는 한, 추가 변환 단계 (idmap 데몬 프로세스 사용)를 희생해야 하며, 로컬 UID 매핑 메커니즘 또는 데이터베이스가 잘못 구성되었거나 손실되었거나 동기화되지 않으면, 추가적인 실패 점을 도입할 수 있습니다. 사용자 이름의 "@domain" 부분은 특정 이름, 예를 들어 다음의 형식에서 할당된 권한을 나타내는 데 사용될 수 있습니다:
- Kerberos 영역 이름
- Active Directory 도메인 이름
- 운영 시스템 공급업체의 이름 (배포판-별 할당에 대해)
- 컴퓨터의 이름 (장치-별 할당에 대해)
그러나 실제에서 많은 기존 구현은 오직 NFSv4 도메인을 고정 값으로 설정하는 것을 허용하므로, 그것을 무용지물로 만듭니다.