Perché non dovresti MAI modificare il file / etc / shadow direttamente?

In un'altra risposta qui sullo scambio di stack UNIX e Linux Michael D Parker ha scritto , in risposta a qualcuno che affermava che farlo era "sicuro", che:

Di solito non dovresti MAI modificare il file / etc / shadow direttamente.

Così:

Perché non dovresti mai modificare il /etc/shadowfile direttamente?

Ci sono diverse ragioni per non modificare /etc/passwd, /etc/shadow, /etc/group, /etc/gshadowo /etc/sudoersdirettamente, ma piuttosto utilizzare vipw, vigroppure visudo:

• Se si commette un errore di sintassi, potrebbe non essere più possibile accedere o diventare root. L'uso degli strumenti viXXX riduce questo rischio perché lo strumento esegue controlli di integrità prima di modificare il file.
• Se il file viene modificato contemporaneamente, chiunque salverà per ultimo sovrascriverà le modifiche apportate dalle modifiche precedenti. Questo include sia un amministratore modifica del file e il file viene modificato perché un utente chiamato passwd, chsho chfndi cambiare qualcosa sul loro conto. Se si utilizza lo strumento appropriato, si eviteranno modifiche simultanee. Questo è principalmente un problema per i sistemi con più utenti, meno se sei l'unico utente.
• Su alcuni sistemi (principalmente o solo * BSD), vipwaggiorna più file (ad es. /etc/passwdE /etc/master.passwd). Questo non si applica a Linux.
• vipwcrea automaticamente una copia di backup ( passwd-, shadow-, ...), che è utile se ci si rende conto che è stato eliminato accidentalmente una linea. È utile solo se ti rendi conto prima della prossima modifica, quindi non sostituisce il controllo della versione e i backup, ma può essere molto bello se ti rendi conto del tuo errore abbastanza presto. visudonon lo fa.

È possibile modificare direttamente il file. Stai solo assumendo un rischio aggiuntivo senza alcun vantaggio reale.

Esistono sostanzialmente due modi per esaminare questo:

1. Non modificare mai determinati file senza usare gli strumenti prescritti perché probabilmente non sai cosa stai facendo e va bene perché detti strumenti sanno meglio e sono sempre disponibili.

2. Più realisticamente, potresti anche romperlo ora mentre ci stai pensando in modo da poter pianificare in anticipo con una copia di backup e confrontare le differenze dopo averlo fatto perché loginprobabilmente sono utili le conoscenze di base sui dettagli del processo iniziale di base del sistema avendo per quando lo rompi in qualche altro modo in seguito e ha detto che gli strumenti non ti aiuteranno.

Immagino che probabilmente puoi dire quale consiglio. Dico che se un argomento ti interessa anche solo per un momento potresti anche capitalizzare su quella curiosità e acquisire una nuova abilità mentre ci sei. Soprattutto uno come questo - il shadowfile è in un formato abbastanza semplice, e quel poco che ne so ho imparato dopo averlo rotto accidentalmente - e non era il risultato di una modifica che ho fatto su quel file.

Piuttosto il mio problema si è verificato dopo che qualche altro errore con un database di gestione dei pacchetti ha portato il gestore pacchetti a sovrascriverlo senza salvare un backup e tutti gli utenti sul sistema sono stati resi kaput . Ulteriori ignoranti tentativi di pasticciatura delle riparazioni non fanno altro che diffondere il danno ad altri file correlati e non passò molto tempo prima che dovessi ripristinare la maggior parte dei /etcfile di testo da un backup (meno recente di quanto sperato) .

Dopo averlo fatto e verificato di averlo fatto in uno stato praticabile, ho deciso di farlo deliberatamente, meticolosamente di nuovo. E ancora una volta. Questo è stato tutto qualche mese fa, ma oggi sono fiducioso di poter diagnosticare l'origine di un loginproblema con una volta su un singolo file di registro sul mio sistema e risolverlo con qualsiasi editor di base (e forse fornito uno sguardo o due a man 5 problem_file) hanno fornito solo l'accesso di base ai root fs interessati. Non è stato ottenuto a buon mercato - mi ci è voluto quasi tutto il giorno - ei relativi file di configurazione sono sparsi in tutta la directory (e anche alcuni - come Linux PAM /var/run/no_login- su altri supporti) - ma valeva la pena farlo. E avrebbe potuto essere più economico con un po 'di riflessione.

La morale di questa storia è che è probabilmente non è una buona cosa che il formato del file di configurazione mission-critical come shadow, passwd, groups, shellsdovrebbe essere così opaco per noi che dobbiamo impiegare speciali strumenti di modifica che può o non può correggere il nostro lavoro in modi e per ragioni che non capiamo solo per effettuare un semplice cambiamento. Almeno, penso, vale la pena dedicare del tempo a capire esattamente cosa farebbero diversamente da noi.

Probabilmente è una buona cosa, tuttavia, che una volta acquisiti familiarità con la modifica di detti file, corriamo il rischio di creare al loro interno e di salvare successivamente in essi errori tipografici o sintattici semplici che sono disponibili strumenti che possono ricontrollare il nostro lavoro in modi e per motivi che già comprendiamo prima di applicare le nostre modifiche blase.

Contrappunto: se è necessario copiare un set di accessi utente da un server a un altro, senza conoscere le loro password correnti o assegnandone di nuove, è necessario modificare direttamente / etc / shadow per inserire il campo della password con hash. vipw non ti consente di toccare quel campo, è solo "*"

Aggiornamento: o in questo caso usa chpasswd -e "password con hash", ma può essere fatto solo direttamente sul computer. Se si stava lavorando con una serie di file che non sono stati ancora distribuiti su una macchina (ad es. Macchina virtuale), la modifica diretta potrebbe essere l'unica soluzione.

cioè Di solito c'è uno strumento per fare ciò che vuoi fare senza modificare direttamente / etc / shadow, devi solo sapere di cosa si tratta ...

Un altro motivo per cui è necessario modificare questi file è se si stanno modificando i file in un'immagine del filesystem che si avvierà su un altro sistema e sarà necessario eseguire il debug di quel sistema dopo l'avvio. Ad esempio, il file system epheremal MAAS utilizzato in caso di messa in servizio non riuscita o in modalità di salvataggio.

Mai dire mai ... a meno che tu non lo intenda.