Ubuntu, відновлення працездатності команди sudo
Якось ставив спробувати Ubuntu Server 14.04 на віртуалку (хочу вдома запиляти медіа-сервер), трапилася в мене одна неприємна історія. Потрібно було поміняти рекурсивно права на папку, недовго думаючи, я вирішив виконати таку команду:
>>sudo chmod 777 –R /some/folder
після чого, у мене виявилися переписані права на каталог із sudo (/usr/lib/sudo і на кілька інших) і я більше не міг діяти від імені суперкористувача (оужас!). Сталося це тому, що в папку, на яку я змінював права, був примонтований кореневий розділ системи, пропустивши цей момент я по дурниці переписав права на всі файли. , що "sudo: /usr/bin/sudo повинен належати користувачеві з uid 0 і мати біт setuid". (Для довідки: як правило, root-користувач має id, який дорівнює 0, але тут це не відіграє ролі) Помацавшись трохи в мережі, рішення так і не знайшов, принаймні всі запропоновані мені не підходили. Більшість тем із такою самою проблемою на форумах закінчувалися просто перестановкою системи. Через мою впертість це теж був неприйнятний варіант.
Вихід для мого випадку полягав у перезавантаженні в Recovery Mode і послідовному виставленні необхідних прав на папки, в яких містяться життєво важливі команди, тому що система лаялася на неправильні права на ці папки та файли. пункт «Додаткові параметри для Ubuntu», потім рядок з Recovery Mode та в меню вибрати root:
Тепер можна діяти з-під рут-користувача. Перед будь-якими змінами необхідно спочатку перемонтувати файлову систему з можливістю не тільки читання (як вона(за замовчуванням в режимі відновлення), але й для запису:
#mount –o remount , rw /
Потім змінюємо права на файли папки. Можна звіряти дані права доступу на файли/папки з іншою системою, якщо є під рукою (Я так і робив)
Для початку не завадило б повернути кореневому розділу більш-менш прийнятні права доступу (цю команду зміни прав доступу для кореневого каталогу слід використовувати тільки якщо раніше були змінені права доступу до всіх файлів і папок, а не до окремих).
Для /usr/bin/sudo необхідно встановити:
#chmod 4755 /usr/bin/sudo
Перший біт в описі прав доступу (тут рівний 4) відповідає за setuid, setgid і sticky (про це докладніше можна прочитати в мережі), на відсутність setuid якраз і лаялася система.
Потім система повідомляє (якщо спробувати використати sudo від користувача), що "sudo: /usr/lib/sudo/sudoers.so має бути доступний на запис тільки власнику". Тому ми робимо:
#chmod 0755 /usr/lib/sudo/sudoers.so
Після цього система лається на те, що «запис у /etc/sudoers дозволено всім». Виправляється це так:
#chmod 0440 /etc/sudoers
Потім потрібно поправити права на /etc/sudoers.d, тому що «sudo: запис у /etc/sudoers.d дозволено всім» (рекурсивно, оскільки це каталог):
#chmod 0755 -R /etc/sudoers.d
І на /var/lib/sudo, так як система говорить, що "/var/lib/sudo доступно для запису не тільки власнику (040777), дозволи повинні мати вигляд 0700":
#chmod 0700 -R /var/lib/sudo
Мені доводилося після кожної команди зміна доступу пробувати використовувати sudo від користувача (досі в режимі відновлення виконати su user_name і потім будь-яку команду з sudo;повернутися назад до рута потрібно виконати exit), щоб з'ясувати на які ще неправильні права доступу скаржиться система. Якщо у вас, як і у мене були рекурсивно змінені права доступу на весь кореневий розділ, то після цього краще вручну встановити потрібні права на всі критично важливі файли і папки. Або пошукати в мережі спосіб більш витончений. Ну або перевстановити систему =)