Perché posso creare utenti con lo stesso UID?

La mia comprensione degli UID è che è un numero intero positivo univoco assegnato da un sistema operativo simile a Unix a ciascun utente. Ogni utente viene identificato nel sistema dal suo UID e i nomi utente vengono generalmente utilizzati solo come interfaccia per l'uomo.

Come possono due utenti avere lo stesso UID, non è un conflitto per il mio sistema e i miei pacchetti?

root@kdc:~# id test12
uid=1005(test10) gid=1000(server) groups=1005(test10)
root@kdc:~# id test13
uid=1005(test10) gid=1000(server) groups=1005(test10)
root@kdc:~#

Ho aggiunto due utenti con lo stesso UID e GID: test12e test13

L'output di /etc/passwd:

client@kdc:~$ cat /etc/passwd | grep test12
test12:x:1005:1000::/home/test12:/bin/sh
client@kdc:~$ cat /etc/passwd | grep test13
test13:x:1005:1000::/home/test13:/bin/sh

Ho aggiunto gli utenti di useradd -ou 1005 -g1000 username.

Mi sono confuso qual è lo scopo di questo, e può influire su autorizzazioni e registri utenti ecc. Quindi ora se un utente viene aggiunto uid=0e gid=0avrà privilegi come un account root?

La risposta qui è che Linux non ti protegge da te stesso.

Se vuoi davvero su rootandare nei file / etc e dare a tutti gli utenti lo stesso UID, puoi farlo. È solo un file di testo.

Ma non dovresti davvero e avrà conseguenze indesiderate.

Ci sono effettivamente validi motivi per questo. Ad esempio, lavoravo in un laboratorio in cui ognuno di noi aveva il proprio computer ma il nostro $HOMEera in un'unità condivisa esportata da un server. Quindi il mio $HOMEera

/users/terdon

Dal momento che la /userscartella non era effettivamente sul mio computer locale ma esportata su NFS, per qualsiasi analisi che fosse pesante sull'I / O, avrei usato i dati memorizzati sui miei dischi rigidi locali per non gravare sulla rete del laboratorio. A tal fine, io e tutti gli altri avevamo due utenti: uno a livello di sistema e uno locale alla macchina in questione. La casa dell'utente locale era

/home/localuser

Tuttavia, ho bisogno di avere pieno accesso ai miei file se ero entrato come terdono come localusere il modo in cui il nostro amministratore di sistema aveva attuato che era dando sia localusere terdonlo stesso UID. In questo modo, ho potuto manipolare liberamente i miei file locali indipendentemente da quale utente ero attualmente connesso.

Due utenti possono avere lo stesso UID perché è solo un numero in un file di testo, quindi è possibile impostarlo su tutto ciò che si desidera, incluso un valore già utilizzato. Come hai visto, farlo non è una buona idea.

In realtà è abbastanza comune avere due utenti con lo stesso ID. Su FreeBSD, di solito ci sono due utenti con UID 0: root e toor. Root usa la shell / bin / sh integrata e toor usa una shell diversa, di solito bash.

I sistemi Unix e Linux generalmente non fanno nulla per vietare i duplicati nel /etc/passwdfile. L'intento di questo file è di associare un UID a un nome fisico che può essere visualizzato dagli strumenti della riga di comando come lsquando l'utente sta elencando i file.

$ ls -n | head -5
total 986000
drwxrwxr-x.   3 1000 1000      4096 Feb 13 19:51 1_archive_sansa
-rw-rw-r--.   1 1000 1000    760868 Dec 16 08:21 2.18.x Database Scheme.jpg
-rw-rw-r--.   1 1000 1000       972 Oct  6 20:26 abcdefg
drwxrwxr-x.   2 1000 1000      4096 Feb 11 03:34 advanced_linux_programming

L'altro scopo previsto di questo file è di specificare quale shell otterrà un utente al momento del login.

$ getent passwd saml
saml:x:1000:1000:saml:/home/saml:/bin/bash

Un vettore di attacco comune su sistemi di tipo Unix è l'aggiunta di linee come queste al /etc/passwdfile di un sistema :

$ getent passwd r00t
r00t:x:0:0:root:/root:/bin/bash

$ getent passwd toor
toor:x:0:0:root:/root:/bin/bash

Il ruolo del /etc/passwdfile NON ha lo scopo di tenere traccia esclusivamente degli account utente. Il ruolo di tracciamento di username e password è responsabilità del /etc/shadowfile. I file come /etc/passwde /etc/groupsono realmente pensati per fornire un nome leggibile quando il sistema elenca i file dai dischi.

Ricorda che i tuoi file vengono scritti sul disco utilizzando i nomi non reali di UID / GID.

$ stat afile 
  File: ‘afile’
  Size: 0           Blocks: 0          IO Block: 4096   regular empty file
Device: fd02h/64770d    Inode: 6560621     Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/    saml)   Gid: ( 1000/    saml)
Context: unconfined_u:object_r:user_home_t:s0
Access: 2014-02-27 15:54:21.852697029 -0500
Modify: 2014-02-27 15:54:21.852697029 -0500
Change: 2014-02-27 15:54:21.852697029 -0500
 Birth: -

Notare il Uid:e Gid:, i numeri sono ciò che è effettivamente scritto sul disco!

In Linux, tutti gli utenti e i gruppi sono in realtà solo numeri. Questo è ciò idche mostra l'output del comando che hai pubblicato.

Il /etc/passwdfile associa i nomi utente agli ID utente (numeri) e nell'esempio che hai fornito, hai semplicemente mappato due nomi utente allo stesso ID utente.

In effetti, hai creato un utente, test12ID 1005, che ha anche un secondo nome utente test13. Tuttavia, il sistema mapperà l'UID 1005 sul primo nome utente che trova, che sarebbetest12

Linux "ti permette" di farlo perché non esiste un sistema che ti impedisca di farlo. /etc/passwdè solo un file di testo, i nomi utente sono associati all'UID trovato per la loro voce in quel file, gli UID sono associati al primo nome utente trovato in quel file.

Ma quello che hai creato è una situazione confusa per altri amministratori di systams; evitarlo modificando l'UID ditest13

Il motivo per cui questo è consentito oggi è semplicemente perché il sistema non lo impedisce.

Se questo cambiasse, romperebbe quei sistemi in cui gli amministratori hanno avuto un uso per questa funzione (vedi l'esempio di Terdon). Quindi non è mai stato cambiato e non credo che lo farà mai.

Inizialmente c'erano solo i file passwd e di gruppo e servivano al loro scopo. non vi era alcun comando adduser , nessun addgroup , i file venivano modificati da root usando vi o ed.

Ci sono state alcune stranezze!

Per ricordare il prossimo ID utente da usare, era comune per gli amministratori avere un utente speciale come ultima riga con un nome utente !(perché !era un nome utente non valido) e quella voce veniva utilizzata per memorizzare il successivo ID utente. Crudo, lo ammetto, ma ha funzionato! Quindi perché rompere un intestino rendendolo più complicato, simile allo sviluppo agile di oggi.

C'erano difetti noti. L'essere principale, che doveva essere leggibile dal mondo, in modo che i programmi di utilità come lspotevano mappare user-id => name. Ciò significava che chiunque poteva vedere la password crittografata di tutti e tutti gli utenti e gli ID nel sistema.

Alcuni sistemi Unix hanno iniziato a introdurre un paio di script di shell adduser addgroup, spesso questi sono stati ignorati, perché erano incoerenti tra Unix, quindi la maggior parte delle persone ha continuato con la modifica manuale.

Ci sono voluti alcuni anni, prima che il shadowfile delle password fosse inventato, questo forniva un po 'più di sicurezza, nascondendo le password crittografate. Ancora una volta, è stata aggiunta una complessità sufficiente, ma era ancora abbastanza grezza e semplice. Le utility useradde groupaddsono state introdotte, che sono state mantenute shadowe shadow-aggiornate. Per cominciare, si trattava spesso di semplici wrapper di script shell attorno alle utility adduser / addgroup proprietarie dei fornitori . Ancora una volta, è bastato continuare.

Le reti di computer stavano crescendo, le persone stavano lavorando su più di una volta per fare i lavori, quindi l'amministratore dei passwd/groupfile stava diventando un incubo, specialmente con NFS, quindi arrivano Pagine Gialle note anche come NIS per alleviare il carico.

Ormai stava diventando ovvio che era necessario qualcosa di un po 'più flessibile e fu inventata la PAM. Quindi, se tu fossi davvero sofisticato e volessi un sistema di autenticazione centralizzato, sicuro, unico, tutte le campane e fischietti che chiameresti ad un server centrale per l'autenticazione, forse un server Radius, un server LDAP o Active Directory.

Il mondo era cresciuto. Ma i file passwd / group / shadow sono rimasti per noi utenti / sviluppatori / lab più piccoli. Non avevamo ancora bisogno di tutte le campane e fischietti. Immagino che la filosofia fosse un po 'cambiata in "Se avessi intenzione di migliorarla, non l'avresti usata affatto" , quindi non preoccuparti.

Questo è il motivo per cui non penso che il semplice file passwd cambierà mai. Non ha più senso, ed è semplicemente fantastico per quei Raspberry Pi da £ 30 con 2 forse 3 temperature di monitoraggio dell'utente e feed di Twitter. OK, devi solo essere un po 'attento con i tuoi ID utente se li vuoi unici, e non c'è nulla che impedisca all'entusiasta di impacchettare useradd in uno script che seleziona prima l'id univoco successivo da un database (file) per impostare un ID unico, se è quello che vuoi. Dopotutto è open source.

Il /etc/passwdfile associa solo nomi utente simbolici al vero ID utente. Se si creano deliberatamente due nomi simbolici associati a un ID utente, ciò consentirà.

Ciò non significa che sia una buona idea farlo davvero. Alcune persone potrebbero aver trovato casi di utilizzo molto specifici in cui possono sfruttare questa funzionalità, ma in generale non dovresti farlo.

Linux (e altri UNIX) ritengono che l'amministratore sappia cosa stanno facendo. Se gli dici di fare qualcosa di stupido, allora è colpa tua, più o meno allo stesso modo che se dici alla tua auto di guidare su una scogliera non puoi andare dai produttori e chiederti perché l'auto ti ha permesso di farlo.

Esistono identificatori che il sistema operativo prevede essere univoci, ma vengono utilizzati per il monitoraggio dell'hardware. La conoscenza che un determinato IDentificatore univoco universale corrisponde a un disco rigido contenente file di sistema può aiutarlo a continuare a funzionare se la configurazione hardware cambia. Microsoft chiama questi IDentificatori univoci globali e li utilizza per tenere traccia di tutto il software Windows. Ironia della sorte, questi acronimi sono stati scelti male.

Dal punto di vista del sistema operativo, la maggior parte delle modifiche all'identificatore di utenti e gruppi equivale a cambiare la sua interfaccia esterna. Potrebbe funzionare normalmente nonostante le collisioni; principalmente ciò che è richiesto agli utenti e ai gruppi di sistema è che esistano. Non può sapere cosa richiedono gli utenti. In situazioni come questa, la filosofia di Unix è che il sistema operativo dovrebbe presumere che gli amministratori sappiano cosa stanno facendo e dovrebbero aiutarli a farlo rapidamente.

Ho trovato alcune prove che supportano la risposta di @ andybalholm.

Da APUE , §8.15:

Qualsiasi processo può scoprire il suo ID utente reale ed efficace e l'ID gruppo. A volte, tuttavia, vogliamo scoprire il nome di accesso dell'utente che esegue il programma. Potremmo chiamare getpwuid( getuid()), ma cosa succede se un singolo utente ha più nomi di accesso, ognuno con lo stesso ID utente? ( Una persona potrebbe avere più voci nel file password con lo stesso ID utente per avere una shell di login diversa per ciascuna voce .) Il sistema normalmente tiene traccia del nome in cui effettuiamo l'accesso (Sezione 6.8) e la getloginfunzione fornisce un modo per recuperare quel nome di accesso.

....

Dato il nome di accesso, possiamo quindi utilizzarlo per cercare l'utente nel file della password, ad esempio per determinare la shell di accesso getpwnam.

A proposito, vorrei sapere se si può passare a un'altra shell mentre si è connessi.