현재 CentOS-7을 사용하여 새 Linux 서버를 설치하고 있습니다. 이전에는 모든 컴퓨터에서 CentOS-6을 사용하고 내 계정에 uid=555를 사용했습니다. 그러나 CentOS-7에서는 uid <= 999가 시스템용으로 예약되어 있는 것 같습니다(온라인 일부 기사에 따르면). 테스트 목적으로 다음과 같이 uid = 555로 계정을 만들어 보았습니다.
# useradd -u 555 {내 로그인 이름}
그런 다음 CentOS-7에서도 명령에 경고 등없이 새 계정이 생성되었습니다.
나는 uid <= 999가 "시스템을 위해 예약되어 있다"는 것을 알고 있지만 실제로 위의 uid(555)를 계속 사용하는 데 심각한 문제가 있습니까? 아니면 앞으로 새로운 서비스에서 555를 사용할 가능성이 있으므로 555 사용을 피해야 합니까? 어떤 조언이라도 감사하겠습니다!
편집하다
새 머신(Centos-7)의 /etc/login.defs가 표시됩니다.
# Min/max values for automatic uid selection in useradd
#
UID_MIN 1000
UID_MAX 60000
그리고 내 오래된 컴퓨터(Centos-6)에서는 다음과 같았습니다.
# Min/max values for automatic uid selection in useradd
#
UID_MIN 500
UID_MAX 60000
그래서 다른 UID_MIN이 있습니다. 또한 내 새 컴퓨터의 /etc/passwd는 다음과 같습니다.
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
operator:x:11:0:operator:/root:/sbin/nologin
games:x:12:100:games:/usr/games:/sbin/nologin
ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
nobody:x:99:99:Nobody:/:/sbin/nologin
pegasus:x:66:65:tog-pegasus OpenPegasus WBEM/CIM services:/var/lib/Pegasus:/sbin/nologin
ods:x:999:998:softhsm private keys owner:/var/lib/softhsm:/sbin/nologin
systemd-bus-proxy:x:998:996:systemd Bus Proxy:/:/sbin/nologin
systemd-network:x:192:192:systemd Network Management:/:/sbin/nologin
dbus:x:81:81:System message bus:/:/sbin/nologin
polkitd:x:997:995:User for polkitd:/:/sbin/nologin
apache:x:48:48:Apache:/usr/share/httpd:/sbin/nologin
tss:x:59:59:Account used by the trousers package to sandbox the tcsd daemon:/dev/null:/sbin/nologin
colord:x:996:993:User for colord:/var/lib/colord:/sbin/nologin
abrt:x:173:173::/etc/abrt:/sbin/nologin
unbound:x:995:992:Unbound DNS resolver:/etc/unbound:/sbin/nologin
usbmuxd:x:113:113:usbmuxd user:/:/sbin/nologin
libstoragemgmt:x:994:991:daemon account for libstoragemgmt:/var/run/lsm:/sbin/nologin
saslauth:x:993:76:Saslauthd user:/run/saslauthd:/sbin/nologin
dirsrv:x:389:389:389-ds-base:/usr/share/dirsrv:/sbin/nologin
rpc:x:32:32:Rpcbind Daemon:/var/lib/rpcbind:/sbin/nologin
amandabackup:x:33:6:Amanda user:/var/lib/amanda:/bin/bash
pcp:x:388:388:Performance Co-Pilot:/var/lib/pcp:/sbin/nologin
geoclue:x:387:386:User for geoclue:/var/lib/geoclue:/sbin/nologin
setroubleshoot:x:386:385::/var/lib/setroubleshoot:/sbin/nologin
postfix:x:89:89::/var/spool/postfix:/sbin/nologin
memcached:x:385:384:Memcached daemon:/run/memcached:/sbin/nologin
rtkit:x:172:172:RealtimeKit:/proc:/sbin/nologin
mysql:x:27:27:MariaDB Server:/var/lib/mysql:/sbin/nologin
qemu:x:107:107:qemu user:/:/sbin/nologin
radvd:x:75:75:radvd user:/:/sbin/nologin
chrony:x:384:383::/var/lib/chrony:/sbin/nologin
ntp:x:38:38::/etc/ntp:/sbin/nologin
sssd:x:383:382:User for sssd:/:/sbin/nologin
rpcuser:x:29:29:RPC Service User:/var/lib/nfs:/sbin/nologin
nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin
pulse:x:171:171:PulseAudio System Daemon:/var/run/pulse:/sbin/nologin
hsqldb:x:96:96::/var/lib/hsqldb:/sbin/nologin
tomcat:x:91:91:Apache Tomcat:/usr/share/tomcat:/sbin/nologin
pkiuser:x:17:17:Certificate System:/usr/share/pki:/sbin/nologin
gdm:x:42:42::/var/lib/gdm:/sbin/nologin
gnome-initial-setup:x:382:379::/run/gnome-initial-setup/:/sbin/nologin
avahi:x:70:70:Avahi mDNS/DNS-SD Stack:/var/run/avahi-daemon:/sbin/nologin
sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin
tcpdump:x:72:72::/:/sbin/nologin
oprofile:x:16:16:Special user account to be used by OProfile:/var/lib/oprofile:/sbin/nologin
위에 표시된 uid를 보면 새 서비스에서 사용하는 uid는 999(ods) -> 998(systemd-bus-proxy) -> 997(polkitd) -> ... -> 993(saslauth)인 것 같습니다. . 따라서 (미래에) 다른 새로운 서비스가 이 체계를 따른다면 555를 사용할 때 (나에게) 위험이 거의 없을 수 있습니다. 참고로, 나를 제외한 다른 사용자는 이미 uid >= 1000을 가지고 있으므로 문제가 없습니다. 하지만 다른 컴퓨터(Mac 포함)에서는 555를 사용해 왔기 때문에 앞으로는 uid >= 1000을 사용하는 것이 더 나은지 여전히 궁금합니다.
답변1
글쎄요, 그 질문을 해주셔서 기쁘네요. 흥미로운 질문이거든요.
위키피디아에 따르면:
Linux Standard Base Core 사양은 0~99 범위의 UID 값이 시스템에 의해 정적으로 할당되어야 하고 애플리케이션에 의해 생성되어서는 안 되는 반면, 100~499 범위의 UID는 시스템 관리자가 동적 할당을 위해 예약해야 한다고 명시하고 있습니다. 및 설치 후 스크립트. [4]
FreeBSD에서 패키지에 UID가 필요한 포터는 50에서 999 범위의 무료 UID를 선택한 다음 정적 할당을 등록할 수 있습니다. [5][6]
일부 POSIX 시스템은 500(OS X, Red Hat Enterprise Linux)부터 시작하여 새 사용자에게 UID를 할당하고, 다른 시스템(openSUSE, Debian[7])은 1000부터 시작합니다. 많은 Linux 시스템에서 이러한 범위는 useradd 및 유사한 도구에 대해 /etc/login.defs에 지정됩니다.
회사 네트워크(예: LDAP 및 NFS 서버를 통해)의 중앙 UID 할당은 클라이언트 컴퓨터에 로컬로 할당된 UID와의 잠재적인 충돌을 피하기 위해 1000보다 훨씬 큰 UID 번호로만 제한될 수 있습니다. NFSv4는 프로토콜 패킷에서 사용자(및 그룹)를 식별하기 위해 정수 대신 "user@domain" 이름을 사용하여 숫자 식별자 충돌을 방지하는 데 도움이 될 수 있지만 추가 변환 단계가 필요합니다.
원천:https://en.wikipedia.org/wiki/User_identifier
따라서 제가 얻은 것은 다음과 같습니다.
- 50 미만 ~ 99 == 시스템 응용 프로그램과 충돌할 위험이 높음
- 499 미만 = 프로그램과 충돌할 위험
- 1000 미만 = 프로그램과 충돌할 위험이 적음
- 네트워크 UID 시스템의 경우 큰 숫자만 사용하고 싶습니다
최악의 경우, 여전히 제가 이해하는 바에 따르면, 다른 프로그램의 파일이나 프로세스와의 상호 작용을 허용하는 프로그램이나 사용자 또는 그룹이 있을 수 있습니다. 대부분의 소규모 서버에서는 그렇지 않은 것 같습니다. 별것 아니지만, 그럴 수도 있습니다. 대규모 시스템에서는 심각한 보안 취약점이 됩니다.
답변2
~에서https://systemd.io/UIDS-GIDS/
배포판은 일반적으로 사용 가능한 UID 범위를 두 부분으로 나눕니다.
1…999 → 시스템 사용자. 이러한 사용자는 실제 "사람" 사용자로 매핑되지 않지만 시스템 데몬의 보안 ID로 사용되어 권한을 분리하고 최소 권한으로 시스템 데몬을 실행할 수 있습니다.
1000…65533 및 65536…4294967294 → 기타 모든 것, 즉 일반(인간) 사용자.
...
두 할당 범위에 대한 참고 사항: UID 할당이 발생하면 NSS에서 먼저 충돌이 있는지 확인하고 항목이 발견되면 다른 UID가 선택됩니다.