Più account * NIX con UID identico

Sono curioso di sapere se esiste un comportamento previsto standard e se è considerato una cattiva pratica quando si crea più di un account su Linux / Unix con lo stesso UID. Ho fatto alcuni test su RHEL5 con questo e si è comportato come mi aspettavo, ma non so se sto tentando il destino usando questo trucco.

Ad esempio, supponiamo che io abbia due account con gli stessi ID:

a1:$1$4zIl1:5000:5000::/home/a1:/bin/bash
a2:$1$bmh92:5000:5000::/home/a2:/bin/bash

Ciò significa che:

• Posso accedere a ciascun account usando la propria password.
• I file che creo avranno lo stesso UID.
• Strumenti come "ls -l" elencheranno l'UID come prima voce nel file (a1 in questo caso).
• Evito qualsiasi permesso o problema di proprietà tra i due account perché sono davvero lo stesso utente.
• Ricevo il controllo dell'accesso per ciascun account, quindi ho una granularità migliore nel tracciare ciò che sta accadendo sul sistema.

Quindi le mie domande sono:

• Questa abilità è progettata o funziona esattamente?
• Sarà coerente tra le varianti * nix?
• Questa pratica è accettata?
• Ci sono conseguenze non intenzionali in questa pratica?

Nota, l'idea qui è di usare questo per gli account di sistema e non per i normali account utente.

La mia opinione:

Questa abilità è progettata o funziona esattamente?

È progettato. Da quando ho iniziato a usare * NIX, sei stato in grado di posizionare gli utenti su gruppi comuni. La possibilità che l'UID sia lo stesso senza problemi è solo un risultato previsto che, come tutto, potrebbe causare problemi se gestito in modo errato.

Sarà coerente tra le varianti * nix?

Credo di sì.

Questa pratica è accettata?

Accettato come generalmente usato in un modo o nell'altro, sì.

Ci sono conseguenze non intenzionali in questa pratica?

Oltre al controllo dell'accesso, non hai nient'altro. A meno che tu non voglia esattamente questo, tanto per cominciare.

Funzionerà su tutti gli Unix? Sì.

È una buona tecnica da usare? No. Esistono altre tecniche migliori. Ad esempio, l'uso corretto di gruppi unix e configurazioni "sudo" rigorosamente controllate possono ottenere le stesse cose.

Ho visto esattamente un posto dove questo è stato usato senza problemi. In FreeBSD è tradizionale creare un secondo account root chiamato "toor" (root scritto all'indietro) che ha / bin / sh come shell predefinita. In questo modo, se la shell di root viene incasinata, è comunque possibile accedere.

Non posso fornire una risposta canonica alle tue domande, ma aneddoticamente la mia azienda lo fa da anni con l'utente root e non ha mai avuto problemi con esso. Creiamo un utente 'kroot' (UID 0) il cui unico motivo di esistenza è avere / bin / ksh come shell invece di / bin / sh o bin / bash. So che i nostri DBA Oracle fanno qualcosa di simile con i loro utenti, con 3 o 4 nomi utente per installazione, tutti con gli stessi ID utente (credo che sia stato fatto per avere directory home separate con ciascun utente. Lo abbiamo fatto almeno per dieci anni, su Solaris e Linux. Penso che funzioni come previsto.

Non lo farei con un normale account utente. Come hai notato, dopo il login iniziale tutto torna al nome nel file di registro, quindi penso che le azioni di un utente possano essere mascherate come le azioni di un altro nei registri. Per gli account di sistema, sebbene funzioni alla grande.

Questa abilità è progettata o funziona esattamente?

Progettato in questo modo.

Sarà coerente tra le varianti * nix?

Dovrebbe sì.

Questa pratica è accettata?

Dipende da cosa intendi. Questo tipo di cose risponde a un problema estremamente specifico (vedi account root / toor). In qualsiasi altro posto e stai chiedendo uno stupido problema in futuro. Se non sei sicuro che questa sia la soluzione giusta, probabilmente non lo è.

Ci sono conseguenze non intenzionali in questa pratica?

È abitudine generale trattare nomi utente e UID come intercambiabili. Come alcune altre persone hanno sottolineato, i controlli di accesso / attività saranno imprecisi. Ti consigliamo inoltre di rivedere il comportamento di eventuali script / programmi relativi all'utente (adadd, usermod, script userdel della tua distribuzione, eventuali script di manutenzione periodica, ecc.).

Cosa stai cercando di ottenere con questo obiettivo che non si otterrebbe aggiungendo questi due utenti a un nuovo gruppo e concedendo a quel gruppo le autorizzazioni necessarie?

Ci sono conseguenze non intenzionali in questa pratica?

C'è un problema di cui sono a conoscenza. Cron non gioca bene con questo aliasing UID. Prova a eseguire "crontab -i" da uno script Python per aggiornare le voci cron. Quindi eseguire "crontab -e" nella shell per modificare lo stesso.

Si noti che ora cron (vixie, penso) avrà aggiornato le stesse voci sia per a1 che per a2 (in / var / spool / cron / a1 e / var / spool / cron / a2).

Questo è un comportamento previsto su tutte le distribuzioni che ho visto ed è un trucco comune che "il nemico" usa per nascondere gli account con accesso root.

Non è certamente standard (non l'ho visto in gioco da nessuna parte), ma non ci dovrebbe essere alcun motivo per cui non è possibile utilizzarlo nel proprio ambiente se lo si ritiene opportuno.

L'unica cosa che viene in mente in questo momento è che ciò potrebbe rendere difficile l'auditing. Se hai due utenti con lo stesso uid / gid, credo che avrai difficoltà a capire quale ha fatto cosa durante l'analisi dei log.

La condivisione di ID di gruppi primari è comune, quindi la domanda ruota davvero attorno all'UID .

L'ho già fatto in precedenza per dare a qualcuno l'accesso alla radice, senza dover divulgare la password di root, che ha funzionato bene. (anche se sudo sarebbe stata una scelta migliore, penso)

La cosa principale di cui sarei cauto è come eliminare uno degli utenti: il programma potrebbe confondersi ed eliminare entrambi gli utenti, oppure file appartenenti a entrambi o cose simili.

In effetti, penso che i programmatori probabilmente assumano una relazione 1: 1 tra utente e UID, quindi potrebbero esserci conseguenze impreviste con altri programmi simili a quelli che ho descritto per userdel.

A proposito: questa domanda / risposta è stata aggiornata per i SO di oggi.

Citando da redhat: gestione delle assegnazioni univoche di UID e GID , descrive l'uso di UID e GID e la loro gestione e come generatori (server ID)

deve generare valori UID e GID casuali e allo stesso tempo garantire che le repliche non generino mai lo stesso valore UID o GID. La necessità di numeri UID e GID univoci potrebbe persino attraversare domini IdM, se una singola organizzazione ha più domini disparati.

Allo stesso modo, i programmi di utilità che consentono l'accesso al sistema possono comportarsi in modo imprevedibile (stesso riferimento):

Se a due voci viene assegnato lo stesso numero ID, viene restituita solo la prima voce nella ricerca di quel numero.

Il problema si presenta quando il concetto di "primo" è mal definito. A seconda del servizio installato, i nomi utente possono essere mantenuti in un hash di dimensioni variabili che restituirebbe un nome utente diverso in base a fattori incoerenti. (So ​​che questo è vero, dal momento che a volte ho provato a usare 2 nomi utente con un ID, uno essendo un nome utente locale e l'altro un dominio.username che volevo mappare sull'UID (che alla fine ho indirizzato a un modo completamente diverso), ma potrei accedere con "usera", fare un "who" o "id" e vedere "userb" O "usera" - in modo casuale.

Esiste un'interfaccia per il recupero di più valori di UID da un gruppo (i gruppi con un singolo GID sono progettati per essere associati a più UID), ma non esiste un'interfaccia portatile per restituire un elenco di nomi per un UID, quindi chiunque si aspetta lo stesso o un comportamento simile tra sistemi o persino applicazioni sullo stesso sistema può essere infelicemente sorpreso.

In the Sun (now oracle) yp (yellowpages) o NIS (NetworkInformationServices), ci sono anche molti riferimenti a requisiti di unicità. Funzioni speciali e server sono configurati per allocare ID univoci su più server e domini (ad esempio uid_allocd, gid_allocd - Manpage dei demoni di allocatore UID e GID

Una terza fonte che si potrebbe verificare è la documentazione del server Microsoft per NFS Account Mapping. NFS è un protocollo di condivisione file unix e descrivono come le autorizzazioni e l'accesso ai file sono gestiti dall'ID. Lì, scrivono:

• UID. Questo è un numero intero senza segno utilizzato dai sistemi operativi UNIX per identificare gli utenti e deve essere univoco nel file passwd.

• GID. Questo è un numero intero senza segno utilizzato dal kernel UNIX per identificare i gruppi e deve essere univoco nel file di gruppo. Pagina di gestione MS-NFS

Mentre alcuni sistemi operativi possono aver consentito più nomi / UID (derivati ​​BSD, forse?) La maggior parte dei sistemi operativi dipende dal fatto che questo è unico e può comportarsi in modo imprevedibile quando non lo sono.

Nota: sto aggiungendo questa pagina, in quanto qualcuno ha indicato questa voce datata come supporto per utility moderne per ospitare UID / GID non unici ... che la maggior parte non lo fanno.

Inoltre non so se sia una buona idea o meno, ma uso il comportamento sopra riportato in alcuni punti. Principalmente è per gli account che venivano usati per accedere al server ftp / sftp e aggiornare il contenuto del sito web. Non sembrava infrangere nulla e sembrava rendere più semplice la gestione delle autorizzazioni, come sarebbe stato con più account.

Ho appena riscontrato un problema (piuttosto oscuro) derivante dall'uso di più account con lo stesso UID e ho pensato di condividerlo con un esempio del perché questa non è una buona pratica.

Nel mio caso, un fornitore ha impostato un server di database Informix e un server di applicazioni Web su RHEL 7. Durante l'installazione, sono stati creati più account "root" con UID 0 (non chiedermi perché). Vale a dire, "root", "user1" e "user2", tutti con UID 0.

Il server RHEL 7 è stato successivamente unito a un dominio Active Directory usando winbind. A questo punto, il server Informix DB non poteva più avviarsi. L'esecuzione oninitnon riusciva con un messaggio di errore che diceva quello "Must be a DBSA to run this program".

Ecco cosa abbiamo trovato durante la risoluzione dei problemi:

1. L'esecuzione id rooto getent passwd 0(per risolvere l'UID 0 in un nome utente) su un sistema unito ad Active Directory restituisce casualmente "user1" o "user2" anziché "root".

2. Apparentemente Informix faceva affidamento su un confronto di stringhe per verificare se il nome utente testuale dell'utente che lo avviava fosse "root" e non avrebbe funzionato diversamente.

3. Senza winbind, id roote getent passwd 0sarebbe sempre tornare "root" come nome utente.

La correzione era disabilitare la memorizzazione nella cache e la persistenza in /etc/nscd.conf:

enable-cache    passwd      no
persistent      passwd      no

Dopo questa modifica, UID 0 è stato nuovamente risolto in modo coerente in "root" e Informix ha potuto iniziare.

Spero che questo sia utile a qualcuno.