UID가 500 미만인 일반 사용자를 생성하면 어떤 위험이 있습니까? UID가 기존 UID와 중복되지 않는다고 가정하면 어떤 문제가 발생할 수 있습니까?
내가 하고 싶은 일이 아니라 내가 본 일이고 왜 하면 안되는 일인지 궁금합니다. 이 예에서는 RHEL5에 있습니다.
답변1
내재된 위험은 없다고 생각합니다. 단지 시스템 계정과 사용자 계정을 분리하기 위해 수행된 것뿐입니다. 내 경험에 따르면 500 미만의 숫자를 사용하는 것은 Redhatism이며 그 이상은 아닙니다.
Solaris에서는 또한 사용자에게 100부터 시작하는 번호가 할당되는 것을 보았지만 몇 년 후에 2개의 작은 부서의 시스템을 함께 병합하면 여러 사용자가 동일한 UID/GID가 할당되어 악몽으로 이어질 것이라는 사실을 알게 되었습니다.
이는 실제로 UID를 할당할 때 큰 위험/문제가 됩니다. UID는 주어진 파일/디렉토리에 대한 사용자의 inode에 기록되는 것이므로 나중에 find
UID 1234가 소유한 파일을 많이 찾아 5678로 변경하고 싶지 않을 것입니다 .
따라서 관리자는 UID 선택을 신중하게 고려함으로써 향후 문제를 피할 수 있습니다.
500 이상을 사용하는 것은 Redhat(및 기타 Unix)이 스스로 충분한 버퍼를 제공하여 생성해야 할 시스템 계정이 사용자에게 할당된 UID와 혼동되지 않도록 하는 것입니다.
/etc/login.defs
그런데 숫자 500은 구성 파일의 이 설정에 의해 구동됩니다 /etc/login.defs
.
#
# Min/max values for automatic uid selection in useradd
#
UID_MIN 500
UID_MAX 60000
#
# Min/max values for automatic gid selection in groupadd
#
GID_MIN 500
GID_MAX 60000
useradd
/ 명령을 통해 기본 동작을 재정의하려면 adduser
원하는 대로 변경할 수 있습니다.
Useradd 매뉴얼 페이지
매뉴얼 페이지 를 보면 useradd
이 섹션에서 GID의 기본값에 대해 설명하고 있지만 이 참고 사항은 UID에도 적용된다는 것을 알 수 있습니다.
발췌
-g, --gid GROUP
The group name or number of the user´s initial login group. The group name
must exist. A group number must refer to an already existing group.
If not specified, the behavior of useradd will depend on the USERGROUPS_ENAB
variable in /etc/login.defs. If this variable is set to yes
(or -U/--user-group is specified on the command line), a group will be
created for the user, with the same name as her loginname. If the variable
is set to no (or -N/--no-user-group is specified on the command line),
useradd will set the primary group of the new user to the value specified by
the GROUP variable in /etc/default/useradd, or 100 by default.
시스템 계정
매뉴얼 페이지에서 주목해야 할 또 다른 사항 useradd
은 시스템 계정 생성에 관한 사항입니다.
발췌
-r, --system
Create a system account.
System users will be created with no aging information in /etc/shadow,
and their numeric identifiers are choosen in the SYS_UID_MIN-SYS_UID_MAX
range, defined in /etc/login.defs, instead of UID_MIN-UID_MAX (and their
GID counterparts for the creation of groups).
Note that useradd will not create a home directory for such an user,
regardless of the default setting in /etc/login.defs (CREATE_HOME). You
have to specify the -m options if you want a home directory for a system
account to be created.
useradd -r ...
스크립팅에서는 패키지를 설치할 때 이 방법( )을 사용하여 이를 다양한 패키지 관리자(RPM 등)에 통합하는 경우가 많습니다. 이런 방식으로 스크립트를 작성하면 시스템 사용자에게 이미 할당된 UID/GID를 밟을 위험 없이 시스템이 특정 시스템에서 사용 가능한 다음 UID/GID를 자동으로 선택할 수 있습니다.
답변2
실제 위험은 없습니다. 커널은 0이 아닌 사용자 ID 값에 대해서는 신경 쓰지 않습니다. 대부분의 관리 도구도 신경 쓰지 않습니다. 시스템 사용자와 인간 사용자를 구별하는 시스템 부분은 거의 없습니다.
시스템 사용자는 전용 그룹을 갖는 경향이 있으므로 더 많은 그룹에 속하는 계정을 생성할 가능성이 없습니다.
일부 배포판에서는 전용 사용자가 필요한 시스템 서비스가 포함된 패키지를 설치할 때 할당된 사용자를 포함하여 시스템 사용자를 위해 1–499(Red Hat 및 관련 버전) 또는 1–999(Debian 및 관련 버전) 범위를 예약합니다. 데비안의 관례는 범위 1-99가 정적으로 할당되는 것입니다(따라서 해당 범위에서 인간 사용자를 생성하는 것은 시스템 사용자와 충돌할 수 있으므로 매우 나쁜 생각입니다). 반면 범위 100-999는 동적으로 할당됩니다(따라서 인간 사용자를 생성하는 것은 그 범위 내에서 무해합니다). 새로운 시스템 사용자는 무료 사용자 ID를 선택하므로 범위).
디스플레이 관리자가 목록 임계값 아래의 UID를 사용자에게 제공하지 않는 등 사소한 불편이 발생할 수 있습니다.
컴퓨터를 격리할 때 가장 큰 위험은 다른 시스템 관리자를 혼란스럽게 할 수 있다는 것입니다. 사용자 ID를 공유하는 네트워크상의 컴퓨터의 경우 시스템 사용자와 동일한 사용자 ID를 가진 다른 컴퓨터와 충돌이 발생할 수 있습니다. 공유된 사용자 ID가 있는 네트워크에서는 인간 사용자가 1000-65533 또는 심지어 10000-65533 범위를 고수하는 것이 가장 좋습니다.
답변3
커널의 관점에서 보면 특수 사용자는 UID 0 한 명뿐입니다. 관리상의 이유로 UID 범위를 분할하면 생활이 더 쉬워질 수 있습니다. 일반적인 범위는 공급자, 시스템, 로컬 및 글로벌입니다.
공급업체 사용자는 시스템 초기 설치 시 설치되며 공급업체에 의해 정적으로 관리됩니다. 설치된 패키지에 따라 시스템 사용자가 각 컴퓨터에 설치됩니다. 대부분의 사용자 추가/제거 유틸리티에는 이를 개별적으로 처리하기 위한 범위 제한이 있습니다. 로컬 사용자는 일반 사용자이며 컴퓨터별로 할당됩니다. 글로벌 사용자는 중앙 데이터베이스에 의해 할당되지만 모두 일반 사용자입니다. UID 범위를 사용하면 이러한 서로 다른 그룹 간의 충돌을 방지할 수 있습니다. 이러한 컷오프는 다양할 수 있지만 일반적으로 구성 가능합니다.
답변4
PAM 프로필은 일반적으로 UID를 기반으로 결정을 내립니다. 예를 들어 RHEL 7.7의 줄은 다음과 같습니다.
/etc/pam.d/password-auth:auth requisite pam_succeed_if.so uid >= 1000 quiet_success
/etc/pam.d/password-auth:account sufficient pam_succeed_if.so uid < 1000 quiet
따라서 시스템 계정에는 일반 사용자 계정에 필요하지 않은 특별한 권한이 부여됩니다. 또한 uid가 1000 미만인 사용자는 로그인하지 못할 수도 있습니다.