Řešení 1:
Můj názor:
Je tato schopnost navržena nebo je to jen způsob, jak to náhodou funguje?
Je navržen. Od té doby, co jsem začal používat *NIX, můžete umisťovat uživatele do společných skupin. Schopnost mít stejné UID bez problémů je pouze zamýšleným výsledkem, který jako všechno může při nesprávné správě přinést problémy.
Bude to konzistentní napříč variantami *nix?
Věřím, že ano.
Je to uznávaný postup?
Přijímáno jako obecně používané tak či onak, ano.
Má tato praxe nezamýšlené důsledky?
Kromě auditování přihlášení nemáte nic jiného. Pokud jste nechtěli přesně to, pro začátek.
Řešení 2:
Bude to fungovat na všech Unixech? Ano.
Je to dobrá technika k použití? Ne. Existují jiné techniky, které jsou lepší. Například správným používáním unixových skupin a přísně kontrolovanými konfiguracemi „sudo“ lze dosáhnout stejných věcí.
Viděl jsem přesně jedno místo, kde to bylo použito bez problémů. Ve FreeBSD je tradiční vytvořit druhý root účet nazvaný "toor" (root napsán pozpátku), který má /bin/sh jako výchozí shell. Tímto způsobem se můžete přihlásit, pokud se rootův shell zkazí.
Řešení 3:
Nemohu poskytnout kanonickou odpověď na vaše otázky, ale neoficiálně to moje společnost dělá roky s uživatelem root a nikdy s tím neměla žádné problémy. Vytvoříme 'kroot' uživatele (UID 0), jehož jediným důvodem existence je mít /bin/ksh jako shell místo /bin/sh nebo bin/bash. Vím, že naši Oracle DBA dělají něco podobného se svými uživateli, mají 3 nebo 4 uživatelská jména na instalaci, všechna se stejnými uživatelskými ID (věřím, že to bylo provedeno proto, aby každý uživatel měl samostatné domovské adresáře. Děláme to minimálně deset let, na Solarisu a Linuxu. Myslím, že to funguje tak, jak bylo navrženo.
S běžným uživatelským účtem bych to nedělal. Jak jste poznamenali, po počátečním přihlášení se vše vrátí ke křestnímu jménu v souboru protokolu, takže si myslím, že akce jednoho uživatele by mohly být v protokolech maskovány jako akce jiného. Pro systémové účty to funguje skvěle.
Řešení 4:
Má tato praxe nezamýšlené důsledky?
Je tu jeden problém, kterého jsem si vědom. Cron si s tímto aliasingem UID nehraje dobře. Zkuste spustit "crontab -i" ze skriptu Pythonu a aktualizovat položky cron. Poté spusťte "crontab -e" v shellu a upravte to samé.
Všimněte si, že nyní cron (myslím vixie) aktualizuje stejné položky pro a1 i a2 (v /var/spool/cron/a1 a /var/spool/cron/a2).
Řešení 5:
Je tato schopnost navržena nebo je to jen způsob, jak to náhodou funguje?
Navrženo tak.
Bude to konzistentní napříč variantami *nix?
Mělo by, ano.
Je to uznávaný postup?
Záleží na tom, co máte na mysli. Tento typ věcí odpovídá na extrémně specifický problém (viz účty root/toor). Kdekoli jinde a koledujete si o hloupý problém do budoucna. Pokud si nejste jisti, zda je toto správné řešení, pravděpodobně ne.
Má tato praxe nezamýšlené důsledky?
Je obecným zvykem považovat uživatelská jména a UID za vzájemně zaměnitelná. Jak upozornilo několik dalších lidí, audity přihlášení/aktivity budou nepřesné. Budete také chtít zkontrolovat chování všech relevantních skriptů/programů souvisejících s uživatelem (useradd vašeho distra, usermod, skripty userdel, jakékoli skripty pro pravidelnou údržbu atd.).
Čeho se tím snažíte dosáhnout, čeho byste nedosáhli přidáním těchto dvou uživatelů do nové skupiny a udělením této skupiny oprávnění, která potřebujete?