Sto eseguendo un sistema desktop Ubuntu 12.04. Finora ho installato solo alcuni programmi (ho i diritti sudo).

1. Quando controllo l'elenco degli utenti sul sistema, vedo un lungo elenco, come più di 20 utenti, quando sono stati creati questi utenti (ad es. Demone, sistema, sincronizzazione, giochi, polso, ecc.)? In che modo sono collegati ai nuovi programmi installati?

2. Se eseguo un programma sul mio sistema, dovrebbe essere eseguito con il mio UID. Ma facendo un ps , vedo molti altri programmi in esecuzione con UID diversi (come root, demone, avahi, syslog, colord ecc.) - come sono stati avviati questi programmi con UID diversi?

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

I programmi eseguiti normalmente vengono eseguiti con l'ID utente. Sono solo i demoni di sistema eseguiti con il proprio account. Il file di configurazione che indica quando eseguire il daemon indica anche quale utente deve eseguirlo oppure il daemon passa a un account non privilegiato dopo l'avvio. Alcuni demoni richiedono i privilegi amministrativi completi, in modo che corrono sotto la radice conto. Molti demoni devono solo accedere a un dispositivo hardware specifico o a file specifici, quindi vengono eseguiti con un account utente dedicato. Questo viene fatto per motivi di sicurezza: in questo modo, anche se in uno di questi servizi è presente un bug o un'errata configurazione, non può portare a un attacco completo del sistema, poiché l'attaccante sarà limitato a ciò che questo servizio può fare e non lo sarà in grado di sovrascrivere file, spiare processi, ecc.

Sotto Ubuntu, gli ID utente nell'intervallo 0–99 vengono creati durante l'installazione del sistema. 0 è root; molti di quelli compresi tra 1 e 99 esistono solo per motivi storici e sono conservati solo per compatibilità con le versioni precedenti di alcune installazioni locali che li utilizzano (alcune voci extra non fanno male). Gli ID utente nell'intervallo 100–999 vengono creati e rimossi in modo dinamico quando vengono installati o rimossi servizi che richiedono un ID utente dedicato. L'intervallo da 1000 in poi è per utenti umani o qualsiasi altro account creato dall'amministratore di sistema. Lo stesso vale per i gruppi.

Presumo che stai trovando questo elenco di utenti controllando /etc/passwd? Questo è del tutto normale - gli "utenti" servono a portare una serie di autorizzazioni, utili per bloccare non solo gli "utenti reali", ma anche programmi su determinate aree del sistema e tracciare ciò che hanno cambiato (stesso concetto con i gruppi).

Ho inserito uno dei miei /etc/passwdfile Raspberry Pi di seguito come riferimento; noterai l'utente ntopnella parte inferiore di questo file, creato dal programma ntop(monitoraggio della rete). Allo stesso modo sshd, gnatssegnalazione 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?

Nei casi indicati, sono stati creati durante l'installazione del sistema. Questi account utente sono convenzionali, alcuni risalenti a decenni fa. Sono anche standardizzati. La base standard di Linux li divide in:

• la richiesta account utente standard, root, bin, e daemon; e
• l' optional utente standard account adm, lp, sync, shutdown, halt, mail, news, uucp, operator, man, enobody

Altri account utente che sono menzionati qui - pulse, avahi, colord, e Debian-exim(di scegliere uno dal file delle password di py4on) - ci portano alla tua prossima domanda.

In che modo sono collegati ai nuovi programmi installati?

Gli account utente non standard vengono creati e distrutti dagli "script del manutentore" per vari pacchetti, poiché tali pacchetti vengono installati ed eliminati. Un account utente verrà creato dal cosiddetto postinstscript del manutentore del pacchetto , che viene eseguito getentper verificare se l'account utente esiste già e in useraddcaso contrario. In teoria sarebbe stato eliminato dal cosiddetto postrmscript del manutentore del pacchetto , in esecuzione userdel.

In pratica, gli account utente per i pacchetti non vengono eliminati. Il wiki di Fedora (qv) spiega che questo sarebbe irto di difficoltà. Vedi il bug Debian n. 646175 per un esempio di questa logica in azione, dove si decide semplicemente di non cancellare l' rabbitmqaccount utente quando il pacchetto viene rimosso, per risolvere un problema con un demone 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 suo account utente in qualcos'altro e continuare a eseguire lo stesso programma, ma non è consentito il contrario. (Bisogna usare il meccanismo set-UID.)

Il sistema di gestione dæmon funziona come superutente. I suoi dati di configurazione specificano che particolari demoni corrono sotto l'egida di particolari account utente:

• Con System 5 rclo script in /etc/init.dutilizza uno strumento di supporto come start-stop-daemone la sua --chuidopzione.
• Con un responsabile del servizio daemontools famiglia, le runchiamate di script setuidgid, s6-setuidgid, chpst, o runuidcon il nome dell'account utente. Ci sono esempi di ciò in /unix//a/179798/5132 che imposta l' nagiosaccount utente.
• Con upstart c'è una setuidstanza in un file di lavoro, che specifica l'account utente. Questo non è particolarmente preciso, e talvolta si desidera ciò che è descritto su /superuser//a/723333/38062 .
• Con systemd c'è User=un'impostazione nel file dell'unità di servizio, che specifica l'account utente.

Quando il sistema di gestione di demone genera un processo come demone, questi meccanismi rilasciano i privilegi di superutente in modo che il processo di demone continui a essere eseguito sotto l'egida dell'account utente non privilegiato.

C'è una spiegazione abbastanza lunga del perché una buona gestione del demone viene fatta in questo modo. Ma non hai chiesto perché; solo quando, come e da dove. ☺ Una sintesi molto breve, quindi:

I sistemi operativi Unix e Linux isolano i processi in esecuzione sotto l'egida di account utente diversi l'uno dall'altro. Storicamente, se si fosse in grado di subentrare a un demone che correva come superutente, si potrebbe fare qualsiasi cosa si piaccia. Un demone che gira sotto l'egida di un account non privilegiato, d'altra parte, può accedere solo a file, directory, dispositivi e processi che quell'account non privilegiato può fare. Un sistema di programmi mutuamente non fiduciosi, tutti in esecuzione sotto l'egida di diversi account utente e incapaci di accedere / controllare reciprocamente i file / directory / processi / processi / dispositivi reciproci , quindi, è molto più difficile da decifrare.

Ulteriori letture

• Jonathan de Boyne Pollard (2014). Uno sguardo affiancato agli script di esecuzione e alle unità di servizio. . Risposte frequentemente fornite.
• Gestione dell'account negli script del manutentore . Wiki di Debian.
• Confezione: UsersAndGroups . Fedora Project wiki.
• "Capitolo 15. Utenti e gruppi" . Specifiche di base standard Linux 2.1 . 2004. Free Standards Group.
• "9.2 Utenti e gruppi" . Manuale delle politiche di Debian . 2014/11/22. La mailing list dei criteri 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). Abolire i demoni della radice! . DOI 10.1.1.120.3567 .

Su Linux quando installiamo un servizio crea un utente con il suo nome di servizio o simile a quello in modo che non possa accedere ad altri file.