¿Por qué NUNCA debería editar el archivo / etc / shadow directamente?

En otra respuesta aquí en UNIX y Linux Stack Exchange, Michael D Parker escribió , en respuesta a alguien que decía que hacerlo era "seguro", que:

Por lo general, NUNCA debe editar el archivo / etc / shadow directamente.

Entonces:

¿Por qué nunca debes editar el /etc/shadowarchivo directamente?

Hay varias razones para no editar /etc/passwd, /etc/shadow, /etc/group, /etc/gshadowo /etc/sudoersutilizar directamente, sino más bien vipw, vigro visudo:

• Si comete un error de sintaxis, es posible que ya no pueda iniciar sesión o volverse root. El uso de las herramientas viXXX reduce este riesgo porque la herramienta realiza comprobaciones de sanidad antes de modificar el archivo.
• Si el archivo se edita simultáneamente, quien guarde el último anulará los cambios realizados por ediciones anteriores. Esto incluye tanto un administrador de editar el archivo y el archivo está modificando ya que un usuario llamado passwd, chsho chfncambiar algo de su cuenta. Si utiliza la herramienta adecuada, evitará modificaciones concurrentes. Esto es principalmente una preocupación en sistemas con múltiples usuarios, menos si eres el único usuario.
• En algunos sistemas (en su mayoría o solo * BSD), vipwactualiza varios archivos (por ejemplo, /etc/passwdy /etc/master.passwd). Esto no se aplica a Linux.
• vipwcrea automáticamente una copia de seguridad ( passwd-, shadow-, ...), lo cual es útil si se da cuenta de que has borrado accidentalmente una línea. Solo es útil si se da cuenta antes de la próxima edición, por lo que no reemplaza el control de versiones y las copias de seguridad, pero puede ser muy agradable si se da cuenta de su error lo suficientemente pronto. visudono hace esto

Usted puede editar el archivo directamente. Simplemente correrá un riesgo adicional sin una ventaja real.

Básicamente hay dos formas de ver esto:

1. Nunca edite ciertos archivos sin usar las herramientas prescritas porque probablemente no sabe lo que está haciendo y eso está bien porque dichas herramientas saben mejor y siempre están disponibles.

2. De manera más realista, es mejor que lo rompas ahora mientras lo piensas para que puedas planificar con anticipación una copia de seguridad y comparar las diferencias después de hacerlo, porque loginprobablemente valga la pena conocer los entresijos del proceso inicial básico de tu sistema. teniendo para cuando lo rompas de otra manera más tarde y dichas herramientas no te ayudarán.

Supongo que probablemente puedas decir cuál recomiendo. Digo que si un tema te interesa, incluso por un momento, podrías aprovechar esa curiosidad y adquirir una nueva habilidad mientras lo haces. Especialmente uno como este: el shadowarchivo está en un formato bastante básico, y lo poco que sé de él lo aprendí después de romperlo accidentalmente , y no fue el resultado de una edición que hice a ese archivo.

Más bien, mi problema ocurrió después de que algún otro error con una base de datos de administración de paquetes llevó al administrador de paquetes a sobrescribirlo sin guardar una copia de seguridad y todos los usuarios en el sistema se hicieron kaput . Otros intentos de reparos ignorantes en reparaciones solo extendieron el daño a otros archivos relacionados y no pasó mucho tiempo antes de que tuviera que restaurar la mayoría de /etclos archivos de texto de una copia de seguridad (menos reciente de lo esperado) .

Una vez que lo hice y verifiqué que lo tenía en estado viable, decidí hacerlo deliberadamente, meticulosamente, todo de nuevo. Y una vez mas. Todo esto fue hace unos meses, pero hoy sigo confiando en que puedo diagnosticar el origen de un loginproblema con una sola vez de un solo archivo de registro en mi sistema y abordarlo con cualquier editor básico (y tal vez, una mirada o dos en man 5 problem_file) proporcionaron solo acceso básico a la raíz fs afectada. No se obtuvo de forma económica, me llevó la mayor parte del día, y los archivos de configuración relacionados se extienden por todo el directorio (e incluso algunos, como Linux PAM, /var/run/no_loginen otras monturas) , pero valió la pena hacerlo. Y podría haber sido más barato con un poco de previsión.

La moraleja de esta historia es que probablemente es no una cosa buena que el formato de las configuraciones de misión crítica como shadow, passwd, groups, shellsdebe ser tan opaca para nosotros que debemos emplear herramientas especiales de edición que pueden o no pueden corregir nuestro trabajo de una manera y por razones que no entendemos solo para efectuar un cambio simple. Al menos, creo, vale la pena entender exactamente qué harían de manera diferente a lo que nosotros podríamos hacer.

Sin embargo, probablemente sea bueno que una vez que nos familiaricemos lo suficiente con la edición de dichos archivos que corremos el riesgo de hacer dentro de ellos y luego les guardemos errores tipográficos o sintácticos simples de que hay herramientas a nuestra disposición que pueden verificar dos veces nuestro trabajo en formas y por razones que ya entendemos antes de aplicar nuestras ediciones blase.

Contrapunto: si necesita copiar un conjunto de inicios de sesión de usuario de un servidor a otro, sin conocer sus contraseñas actuales o asignarles nuevas, entonces deberá editar / etc / shadow directamente para insertar el campo de contraseña hash. vipw no te deja tocar ese campo, es solo "*"

Actualización: o en este caso use chpasswd -e "contraseña hash", pero eso solo se puede hacer en la computadora directamente. Si estaba trabajando con un conjunto de archivos que aún no se han implementado en una máquina (por ejemplo, una máquina virtual), la edición directa podría ser su única solución.

es decir, generalmente hay una herramienta para hacer lo que quiere hacer sin editar / etc / shadow directamente, solo necesita saber qué es ...

Otra razón por la que necesita editar estos archivos es si está editando los archivos en una imagen del sistema de archivos que iniciará en otro sistema, y ​​necesita depurar ese sistema después del inicio. Por ejemplo, el sistema de archivos efímero MAAS utilizado en una comisión fallida o en modo de rescate.

Nunca digas nunca ... a menos que lo digas en serio.