Soluzione 1:
La mia opinione:
Questa capacità è progettata o è solo il modo in cui funziona?
È progettato. Da quando ho iniziato a utilizzare *NIX, sei stato in grado di inserire utenti in gruppi comuni. La possibilità di avere lo stesso UID senza problemi è solo un risultato previsto che, come tutto, potrebbe portare 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 impreviste a questa pratica?
Oltre al controllo dell'accesso, non hai nient'altro. A meno che tu non volessi proprio questo, tanto per cominciare.
Soluzione 2:
Funzionerà su tutti gli Unix? Sì.
È una buona tecnica da usare? No. Ci sono altre tecniche che sono migliori. Ad esempio, l'uso corretto di gruppi unix e configurazioni "sudo" rigorosamente controllate possono ottenere gli stessi risultati.
Ho visto esattamente un posto in cui questo è stato utilizzato senza problemi. In FreeBSD è tradizione creare un secondo account root chiamato "toor" (radice scritta al contrario) che ha /bin/sh come shell predefinita. In questo modo, se la shell di root viene incasinata, puoi comunque accedere.
Soluzione 3:
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) la cui unica ragione 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, avendo 3 o 4 nomi utente per installazione, tutti con gli stessi ID utente (credo che sia stato fatto per avere directory home separate con ogni utente. Lo facciamo da almeno dieci anni, su Solaris e Linux. Penso che funzioni come previsto.
Non lo farei con un normale account utente. Come hai notato, dopo l'accesso iniziale tutto torna al nome nel file di registro, quindi penso che le azioni di un utente potrebbero essere mascherate da azioni di un altro nei registri. Per gli account di sistema funziona benissimo.
Soluzione 4:
Ci sono conseguenze impreviste a questa pratica?
C'è un problema di cui sono a conoscenza. Cron non funziona bene con questo aliasing UID. Prova a eseguire "crontab -i" da uno script Python per aggiornare le voci di cron. Quindi esegui "crontab -e" nella shell per modificare lo stesso.
Nota che ora cron (vixie, credo) avrà aggiornato le stesse voci sia per a1 che per a2 (in /var/spool/cron/a1 e /var/spool/cron/a2).
Soluzione 5:
Questa capacità è progettata o è solo il modo in cui funziona?
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 impreviste a questa pratica?
È consuetudine generale trattare i nomi utente e gli UID come intercambiabili. Come alcune altre persone hanno sottolineato, i controlli di accesso/attività saranno imprecisi. Ti consigliamo inoltre di rivedere il comportamento di qualsiasi script/programma pertinente relativo all'utente (useradd, usermod, script userdel della tua distribuzione, eventuali script di manutenzione periodica, ecc.).
Cosa stai cercando di ottenere con questo che non sarebbe possibile aggiungendo questi due utenti a un nuovo gruppo e concedendo a quel gruppo le autorizzazioni di cui hai bisogno?