Чому НІКОЛИ не слід редагувати / etc / shadow файл безпосередньо?

Ще в одній відповіді на UNIX & Linux Stack Exchange Майкл Д Паркер написав у відповідь, що хтось сказав, що це було "безпечно", що:

Зазвичай НІКОЛИ не слід редагувати / etc / shadow файл безпосередньо.

Тому:

Чому ніколи не слід редагувати /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файл у досить базовому форматі, і про те, що я мало що знаю про нього, я дізнався, розбивши його випадково - і це не було результатом редагування, внесеного до цього файлу.

Швидше за все, моя проблема виникла після якоїсь іншої помилки з базою даних управління пакетом, що призвело до того, що менеджер пакунків перезаписав його, не зберігаючи резервну копію, і всі користувачі в системі зробили капут . Подальші спроби неосвіченого головотяпства на ремонті тільки поширення пошкодження інших пов'язані файли , і це не було задовго до того, я повинен був відновити більшість /etc«S текстових файлів з (менше , ніж в останній час довгоочікуваного) резервне копіювання.

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

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

Але, мабуть , добре, що коли ми достатньо ознайомимось з редагуванням згаданих файлів, ми ризикуємо зробити всередині них і згодом зберегти для них типографічні чи прості синтаксичні помилки, що в нашому розпорядженні є інструменти, які можуть двічі перевірити наша робота способами та з тих причин, які ми вже розуміємо, перш ніж застосовувати наші зміни в редакції.

Лічильник - якщо вам потрібно було скопіювати набір користувачів із одного сервера на інший, не знаючи їх поточних паролів або призначивши їх нові, вам потрібно буде редагувати / etc / shadow безпосередньо, щоб вставити поле хешованих паролів. vipw не дозволяє торкатися цього поля, це просто "*"

Оновлення: або в цьому випадку використовуйте chpasswd -e "хешований пароль", але це можна зробити лише на комп'ютері безпосередньо. Якщо ви працювали з набором файлів, які ще не розгорнуті на машині (наприклад, віртуальна машина), то редагування безпосередньо може бути вашим єдиним рішенням.

тобто зазвичай існує інструмент для того, щоб робити те, що ви хочете робити, не редагуючи / etc / shadow безпосередньо, вам просто потрібно знати, що це ...

Іншою причиною, що вам потрібно редагувати ці файли, є те, якщо ви редагуєте файли у зображенні файлової системи, яку ви завантажуєте в іншій системі, і вам потрібно буде налагодити цю систему після завантаження. Наприклад, ефірна файлова система MAAS, що використовується в режимі невдалого запуску або в режимі порятунку.

Ніколи не кажіть ніколи ... якщо ви цього не маєте на увазі.