Skip to content

Perché ci sono molti account? Sono l'unico utente

Sentiti libero di diffondere il nostro sito Web e i nostri codici nelle tue reti, abbiamo bisogno del tuo aiuto per far crescere questa comunità.

Soluzione:

Gli account utente sono utilizzati non solo per gli utenti umani veri e propri, ma anche per eseguire i servizi di sistema e talvolta come proprietari dei file di sistema. Questo perché la separazione tra le risorse degli utenti umani (processi, file, ecc.) e quelle dei servizi di sistema richiede gli stessi meccanismi.

I programmi che si eseguono normalmente vengono eseguiti con il proprio ID utente. Solo i demoni di sistema vengono eseguiti con il proprio account. O il file di configurazione che indica quando eseguire il demone indica anche quale utente deve eseguirlo, oppure il demone passa a un account non privilegiato dopo l'avvio. Alcuni demoni richiedono privilegi amministrativi completi, quindi vengono eseguiti sotto l'account root. Molti demoni hanno bisogno di accedere solo a un dispositivo hardware specifico o a file specifici, quindi vengono eseguiti con un account utente dedicato. Questo per motivi di sicurezza: in questo modo, anche se c'è un bug o una configurazione errata in uno di questi servizi, non può portare a un attacco all'intero sistema, perché l'aggressore sarà limitato a ciò che questo servizio può fare e non sarà in grado di sovrascrivere i file, spiare i processi, ecc.

In Ubuntu, al momento dell'installazione del sistema, vengono creati ID utente compresi nell'intervallo 0-99. 0 è root; molti di questi ID vengono creati in seguito. 0 è root; molti di quelli nell'intervallo 1-99 esistono solo per ragioni storiche e sono mantenuti solo per la compatibilità con alcune installazioni locali che li utilizzano (qualche voce in più non fa male). Gli ID utente nell'intervallo 100-999 vengono creati e rimossi dinamicamente quando vengono installati o rimossi servizi che richiedono un ID utente dedicato. L'intervallo da 1000 in poi è per gli utenti umani o per qualsiasi altro account creato dall'amministratore del sistema. Lo stesso vale per i gruppi.

Presumo che si trovi questo elenco di utenti controllando /etc/passwd? Questo è del tutto normale: gli "utenti" servono per avere una serie di permessi, utili per bloccare non solo gli "utenti effettivi" ma anche i programmi che accedono a certe aree del sistema e per tracciare ciò che hanno modificato (lo stesso concetto vale per i gruppi).

Ho inserito uno dei miei Raspberry Pi /etc/passwd qui sotto, come riferimentoce; noterete che l'utente ntop in fondo a questo file, creato dal programma ntop (monitoraggio della rete). Allo stesso modo sshd, gnats segnalazione di bug, ecc.

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh
uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:x:13:13:proxy:/bin:/bin/sh
www-data:x:33:33:www-data:/var/www:/bin/sh
backup:x:34:34:backup:/var/backups:/bin/sh
list:x:38:38:Mailing List Manager:/var/list:/bin/sh
irc:x:39:39:ircd:/var/run/ircd:/bin/sh
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
libuuid:x:100:101::/var/lib/libuuid:/bin/sh
pi:x:1000:1000:,,,:/home/pi:/bin/bash
sshd:x:101:65534::/var/run/sshd:/usr/sbin/nologin
ntp:x:102:104::/home/ntp:/bin/false
statd:x:103:65534::/var/lib/nfs:/bin/false
messagebus:x:104:106::/var/run/dbus:/bin/false
usbmux:x:105:46:usbmux daemon,,,:/home/usbmux:/bin/false
lightdm:x:106:109:Light Display Manager:/var/lib/lightdm:/bin/false
smmta:x:107:110:Mail Transfer Agent,,,:/var/lib/sendmail:/bin/false
smmsp:x:108:111:Mail Submission Program,,,:/var/lib/sendmail:/bin/false
Debian-exim:x:109:113::/var/spool/exim4:/bin/false
ntop:x:110:115::/var/lib/ntop:/bin/false

Quando sono stati creati questi utenti?

Nel caso di quelli citati, sono stati creati al momento dell'installazione del sistema. Questi account utente sono convenzionali, alcuni risalgono a decenni fa. Sono anche standardizzati. Il Linux Standard Base li divide in:

  • il richiesto account utente standard, root, bine daemone
  • il opzionale account utente standard adm, lp, sync, shutdown, halt, mail, news, uucp, operator, mane nobody

Altri account utente che sono menzionati qui - pulse, avahi, colorde Debian-exim (per sceglierne uno dal file delle password di py4on) - ci porta alla domanda successiva.

In che modo questi sono legati all'installazione di nuovi programmi?

Gli account utente non standard sono creati e distrutti dagli "script di manutenzione" per i vari pacchetti, man mano che questi vengono installati e cancellati. Un account utente viene creato dal cosiddetto "script" del pacchetto postinst del pacchetto, che esegue getent per verificare se l'account utente esiste già e useradd in caso contrario. In teoria verrebbe cancellato dal cosiddetto pacchetto postrm del manutentore, che esegue userdel.

In pratica, gli account utente dei pacchetti non vengono cancellati. Il wiki di Fedora (q.v.) spiega che questo sarebbe difficile. Si veda il bug Debian #646175 per un esempio di questa logica in azione, in cui si è deciso semplicemente di non di cancellare il file rabbitmq quando il pacchetto viene cancellato, per risolvere un problema con un daimon che continua a funzionare sotto l'egida di quell'account.

Come sono stati avviati questi programmi con UID diversi?

In Unix e Linux, un processo in esecuzione sotto l'egida del superutente può cambiare il proprio account utente in un altro e continuare a eseguire lo stesso programma, ma non è consentito il contrario. (È necessario utilizzare il meccanismo set-UID).

Il sistema di gestione dei daimon funziona come superutente. I suoi dati di configurazione specificano che particolari daimon funzionano sotto l'egida di particolari account utente:

  • Con il sistema 5 rc lo script in /etc/init.d utilizza uno strumento di aiuto come start-stop-daemon e il suo --chuid ...e la sua opzione --chuid.
  • Con un gestore di servizi della famiglia daemontools, l'opzione run chiama setuidgid, s6-setuidgid, chpst, o runuid con il nome dell'account utente. Ci sono esempi di questo tipo in https://unix.stackexchange.com/a/179798/5132 che impostano il parametro nagios dell'account utente.
  • Con upstart c'è un'opzione setuid in un file di lavoro, che specifica l'account utente. Questo non è particolarmente preciso e a volte si vuole ciò che è descritto in https://superuser.com/a/723333/38062 .
  • Con systemd c'è un'opzione User= nel file dell'unità di servizio, che specifica l'account utente.

Quando il sistema di gestione del daimon genera un processo per essere il daimon, questi meccanismi eliminano i privilegi di superutente in modo che il processo daimon continui a funzionare sotto l'egida dell'account utente non privilegiato.

C'è una spiegazione piuttosto lunga perché la buona gestione dei daimon è fatta in questo modo. Ma voi non avete chiesto perché; solo quando, come e perché. ☺ Un riassunto molto breve, quindi:

I sistemi operativi Unix e Linux isolano i processi in esecuzione sotto l'egida di diversi account utente. Storicamente, se si riusciva a prendere il controllo di un daimon che funzionava come superutente, si poteva fare tutto ciò che si voleva. Un daimon che gira sotto l'egida di un account non privilegiato, invece, può accedere solo ai file, alle directory, ai dispositivi e ai processi di quell'account non privilegiato. Un sistema di programmi daimon che non si fidano l'uno dell'altro tutti in esecuzione sotto l'egida di diversi account utente e incapaci di accedere/controllare l'un l'altro file/directory/processi/dispositivi (interni e fidati), è quindi molto più difficile da decifrare.

Ulteriori letture

  • Jonathan de Boyne Pollard (2014). Un'analisi affiancata degli script di esecuzione e delle unità di servizio.. Risposte frequenti.
  • Gestione degli account negli script del manutentore. wiki Debian.
  • Pacchetto:Utenti e gruppi. Progetto Fedora wiki.
  • "Capitolo 15. Utenti e gruppi". Specifica di base standard di Linux 2.1. 2004. Gruppo per gli standard liberi.
  • "9.2 Utenti e gruppi". Manuale di politica Debian. 2014-11-22. La mailing list sulle politiche Debian.
  • "37.3. Utenti standard". Guida alla distribuzione di RHEL. 11a edizione. 2013. Red Hat.
  • Utenti e gruppi. Arch wiki.
  • Carol Hurwitz e Scott McPeak (2001-02-12). Abolite i demoni delle radici!. DOI 10.1.1.120.3567.

Sezione recensioni e valutazioni

Ricorda che hai l'autorizzazione a valutare questo scritto se hai trovato la risposta.



Utilizzate il nostro motore di ricerca

Ricerca
Generic filters

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.