Quali sono i pericoli legati alla creazione di un utente normale con UID <500?


14

Quali sono i pericoli legati alla creazione di un utente normale con UID <500? Supponendo che gli UID non siano duplicati degli UID esistenti, cosa potrebbe andare storto?

Questo non è qualcosa che voglio fare, ma qualcosa che ho visto e voglio sapere perché non dovrebbe essere fatto. In questo esempio, è su RHEL5.


2
I sistemi derivati ​​da Debian sembrano avviare UID normali a 1000, non a 500.
Keith Thompson,

Risposte:


16

Non credo ci sia alcun rischio intrinseco, questo è qualcosa che viene fatto semplicemente per creare una separazione tra quelli che sono considerati account di sistema e account utente. La mia pratica di usare numeri inferiori a 500, secondo la mia esperienza, è un Redhat-ism, e davvero niente di più.

Su Solaris avevo visto assegnare anche agli utenti numeri a partire da 100, solo a distanza di anni ho scoperto che quando si uniscono i sistemi di 2 dipartimenti più piccoli si crea un incubo, dato che c'erano più utenti nei 2 dipartimenti che avevano lo stesso UID / GID assegnato.

Questo è davvero il principale rischio / mal di testa quando si assegnano gli UID. Dato che l'UID è ciò che alla fine viene scritto nell'inode per i file / le directory di un utente, non vorrai che tutto ciò che ti serve sia performantefind alla ricerca di file di proprietà dell'UID 1234 e che devono cambiarli in 5678 .

Quindi, riflettendo sulla selezione degli UID, gli amministratori possono evitare il mal di testa lungo la strada.

L'uso di 500 e superiori è solo un tentativo da parte di Redhat (e di altri Unix) di darsi abbastanza buffer che qualsiasi account di sistema che potrebbe essere necessario creare non verrà mescolato con gli UID assegnati agli utenti.

/etc/login.defs

Per inciso, il numero 500 è guidato da questa impostazione nel file di configurazione, /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

Puoi cambiarlo in qualsiasi cosa desideri, se desideri sovrascrivere il comportamento predefinito di useradd/adduser comandi.

Pagina man di Useradd

Se dai un'occhiata alla useraddpagina man noterai questa parte che discute il valore predefinito per GID, ma questo commento è applicabile anche agli UID:

estratto

-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.

Account di sistema

Un altro aspetto da tenere presente nella useraddpagina man è questo bit relativo alla generazione dell'account di sistema.

estratto

-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.

È questo metodo ( useradd -r ...) che viene spesso utilizzato dagli script che è incorporato nei vari programmi di ricerca dei pacchetti, come RPM, quando viene installato un pacchetto. Lo scripting in questo modo consente al sistema di selezionare automaticamente il prossimo UID / GID disponibile su un determinato sistema senza il rischio di calpestare UID / GID già assegnati agli utenti del sistema.


1
FWIW, penso che questo sia un generale GNU / Linux-ism, non solo un Red Hat-ism. L'ho visto su tutti i sistemi che utilizzo e non ho mai usato Red Hat.
Strugee,

@strugee - grazie Non volevo fare una dichiarazione troppo ampia e averla fatta tornare per mordermi.
slm

2

Dal punto di vista del kernel esiste un solo utente speciale: UID 0. Dividere intervalli di UID per motivi amministrativi ti semplifica la vita. Le gamme comuni sono fornitore, sistema, locale, globale.

Gli utenti del fornitore vengono installati durante l'installazione iniziale del sistema e sono gestiti staticamente dal fornitore. gli utenti di sistema sono installati per macchina in base ai pacchetti installati. la maggior parte delle utility di aggiunta / eliminazione degli utenti ha un limite di intervallo per gestirle separatamente. gli utenti locali sono utenti regolari e assegnati per macchina. gli utenti globali sono assegnati da un database centrale, ma sono utenti regolari. l'uso di intervalli UID impedisce conflitti tra questi gruppi diversi. dove si trovano questi cut-off può variare ma è generalmente configurabile.


1

Non ci sono pericoli intrinseci nel fare questo. Se si crea un utente con UID 499, questi non avranno alcun privilegio aggiuntivo. Il motivo per cui si suggerisce di non farlo è semplicemente perché gli UID sono in genere riservati agli utenti del sistema. Il problema che si può incontrare nella creazione di tale UID è quando alcuni servizi di sistema prevedono che l'UID sia disponibile. È un po 'come creare un nuovo servizio che gira su un porto ben noto - non c'è necessariamente alcun problema con esso, ma non è una buona pratica e può causare problemi lungo la strada quando si imposta sshd, ftpd, ecc.

Detto questo, ho visto molti sistemi in cui gli utenti sono stati creati con UID <500 senza problemi. Tuttavia, poiché la base di utenti cresce e ora ci sono migliaia di utenti, può diventare difficile distinguere tra account utente e account di sistema. Seguire la regola di nessun UID <500, è molto semplice. Quindi, è anche un bel modo di organizzare gli account.


1

Non esiste alcun pericolo reale. Al kernel non interessano i valori dell'ID utente tranne 0. Non importa nemmeno alla maggior parte degli strumenti di amministrazione - pochissime parti del sistema fanno la differenza tra utenti del sistema e utenti umani.

Gli utenti del sistema tendono ad avere gruppi dedicati, quindi non è probabile che creino account appartenenti a più gruppi di quanto dovrebbero.

Alcune distribuzioni riservano l'intervallo 1–499 (Red Hat e parenti) o 1–999 (Debian e parenti) per gli utenti del sistema, inclusi gli utenti allocati durante l'installazione di un pacchetto contenente un servizio di sistema che richiede un utente dedicato. La convenzione di Debian è che l'intervallo 1–99 è allocato staticamente (quindi la creazione di un utente umano in quell'intervallo è una pessima idea in quanto potrebbe scontrarsi con un utente del sistema) mentre l'intervallo 100-999 è allocato dinamicamente (quindi la creazione di un utente umano in tale intervallo è innocuo, poiché qualsiasi nuovo utente del sistema sceglierà un ID utente gratuito).

Potresti riscontrare piccoli inconvenienti, come i gestori di display che non offrono agli utenti UID al di sotto della soglia nel loro elenco.

Il pericolo principale per una macchina isolata è che probabilmente confonderai i tuoi colleghi amministratori di sistema. Per una macchina in una rete in cui sono condivisi ID utente, è possibile che si verifichino conflitti con altre macchine in cui questi utenti hanno lo stesso ID utente di un utente di sistema. Nelle reti con ID utente condivisi, è meglio attenersi all'intervallo 1000–65533 o anche 10000–65533 per gli utenti umani.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.