Почему Вы никогда не должны редактировать/etc/shadow файл непосредственно?

Есть несколько причин не редактировать /etc/passwd, /etc/shadow, /etc/group, /etc/gshadow или /etc/sudoers напрямую, но вместо этого используйте vipw, vigr или visudo:

• Если вы совершаете синтаксическую ошибку, то, возможно, вы больше не сможете войти в систему или стать корневым пользователем. Использование инструментов viXXX снижает этот риск, так как инструмент делает проверку на вменяемость перед модификацией файла.
• Если файл редактируется одновременно, то кто бы ни сохранил последний, он переопределяет изменения, внесенные предыдущими правками. Сюда входит и администратор, который редактирует файл, и файл, который изменяется, потому что пользователь по имени passwd, chsh или chfn что-то изменил в своей учетной записи. Если вы используете соответствующий инструмент, это предотвратит одновременные изменения. В основном это касается систем с несколькими пользователями, в меньшей степени, если вы единственный пользователь.
• На некоторых системах (в основном или только *BSD), vipw обновляет несколько файлов (например, /etc/passwd и /etc/master.passwd). Это не относится к Linux.
• vipw автоматически создает резервную копию (passwd-, shadow-, ...), что полезно, если вы осознаете, что случайно удалили строку. Это полезно только в том случае, если вы осознаёте это до следующего редактирования, так что это не заменит контроля версий и резервных копий, но это может быть очень хорошо, если вы осознаёте свою ошибку достаточно быстро. visudo не делает этого.

Вы можете редактировать файл напрямую. Вы просто будете рисковать, не имея реальных преимуществ.

На это можно взглянуть двумя способами:

1. Никогда не редактируйте определенные файлы без использования предписанных инструментов, потому что вы, вероятно, не знаете, что делаете, и это нормально, потому что упомянутые инструменты знают лучше и всегда доступны.

2. Более реалистично, вы можете сломать его сейчас, пока вы думаете об этом, так что вы можете планировать заранее с резервной копией и сравнивать различия после того, как вы это сделаете, потому что базовые знания о входе и выходе вашей системы из основного начального процесса login, вероятно, стоят того, чтобы сломать его каким-нибудь другим способом позже, и упомянутые инструменты вам не помогут.

Наверное, вы можете сказать, что я рекомендую. Я говорю, что если какая-то тема интересует вас хотя бы на мгновение, вы можете воспользоваться этим любопытством и приобрести новый навык, пока вы этим занимаетесь. Особенно один такой - файл shadow в довольно базовом формате, и что мало я о нем знаю, я узнал после его случайного взлома - и это не результат редактирования, которое я сделал в этом файле.

Скорее моя проблема возникла после того, как какая-то другая ошибка с базой данных управления пакетами заставила менеджер пакетов перезаписать ее без сохранения резервной копии, и все пользователи системы были сделаны kaput. Дальнейшие неудачные попытки восстановления только распространяли повреждение на другие связанные файлы, и вскоре мне пришлось восстанавливать большинство текстовых файлов /etc из резервной копии (менее свежей, чем ожидалось).

После того, как я сделал это и убедился, что он находится в работоспособном состоянии, я решил сознательно, придирчиво повторить все заново. И еще раз. Всё это было несколько месяцев назад, но сегодня я остаюсь уверенным, что могу диагностировать источник проблемы login один раз в моей системе и обратиться к нему в любом базовом редакторе (и, возможно, взглянув пару раз на man 5 problem_file), я получил только базовый доступ к корневым fs, на которые он был обращён. Это было не дешево - это заняло у меня большую часть дня - и соответствующие конфигурационные файлы разбросаны по всему каталогу (и даже некоторые - такие как Linux PAM /var/run/no_login - на других монтировках) - но это стоило того, чтобы сделать. И это могло бы обойтись дешевле с небольшим запасом прочности.

Мораль этой истории заключается в том, что, вероятно, не хорошо, что формат критичных для миссии конфигураций, таких как shadow, passwd, groups, Оболочки shells должны быть настолько непрозрачны для нас, что мы должны использовать специальные инструменты редактирования, которые могут корректировать или не корректировать нашу работу так или иначе, и по причинам, которые мы не понимаем, просто чтобы осуществить простое изменение. По крайней мере, я думаю, что нам стоит понять, что они будут делать иначе, чем мы.

Наверное, является хорошей вещью, однако, то, что как только мы достаточно освоились с редактированием указанных файлов, мы рискуем сделать внутри них и затем сохранить для них типографские или простые синтаксические ошибки, что в нашем распоряжении есть инструменты, которые могут перепроверить нашу работу способами и по причинам, которые мы уже понимаем, прежде чем применить наши блайзовые правки.

Счетчик - если вам нужно было скопировать набор логинов пользователей с одного сервера на другой, не зная их текущие пароли или не назначая им новые, тогда вам нужно будет отредактировать / etc / shadow для вставки поля хешированного пароля. vipw не позволяет вам касаться этого поля, это просто "*"

Обновление: или в этом случае используйте chpasswd -e "hashed password", но это можно сделать только на компьютере напрямую. Если вы работали с набором файлов, которые еще не были развернуты на машине (например, виртуальной машине), то редактирование напрямую может быть вашим единственным решением.

т.е.Обычно существует инструмент, позволяющий делать то, что вы хотите делать, без непосредственного редактирования / etc / shadow, вам просто нужно знать, что это такое ...

Еще одна причина, по которой вам необходимо редактировать эти файлы, заключается в том, что вы редактируете файлы в образе файловой системы, который вы будете загружать в другой системе, и вам нужно отладить эту систему после загрузки. Например, эфемерная файловая система MAAS, используемая при неудачном вводе в эксплуатацию или в режиме восстановления.

Никогда не говори никогда... если ты этого не хочешь.