Почему вы НИКОГДА не должны редактировать файл / etc / shadow напрямую?

В другом ответе здесь о UNIX & Linux Stack Exchange Майкл Д. Паркер написал в ответ на то, что кто-то сказал, что это было "безопасно", что:

Обычно вы НИКОГДА не должны редактировать файл / etc / shadow напрямую.

Так:

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

Есть несколько причин , чтобы не редактировать /etc/passwd, /etc/shadow, /etc/group, /etc/gshadowили /etc/sudoersнепосредственно, а использовать vipw, vigrили visudo:

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

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

Есть два основных взгляда на это:

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

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

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

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

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

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

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

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

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

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

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

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