I think its gonna rain
читать дальшеКак-то ставил попробовать 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 и последовательном выставлении необходимых прав на папки, в которых содержатся жизненно важные команды, потому что система ругалась на неправильные права на эти папки и файлы.
Чтобы попасть в Recovery Mode в загрузчике нужно выбрать пункт «Дополнительные параметры для Ubuntu», затем строку с Recovery Mode и в меню выбрать root:
Теперь можно действовать из-под рут-пользователя.
Перед любыми изменениями необходимо сначала перемонтировать файловую систему с возможностью не только чтения (как она примонтирована по умолчанию в режиме восстановления), но и для записи:
#mount –o remount , rw /
Затем меняем права на файлы папки.
Можно сверять данные права доступа на файлы/папки с другой системой, если есть под рукой (Я так и делал)
Для начала не помешало бы вернуть корневому разделу более менее приемлемые права доступа (эту команду изменения прав доступа для корневого каталога следует использовать только если ранее были изменены права доступа ко всем файлам и папкам, а не к отдельным), например:
#chmod 0755 –R /
Для /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), чтобы выяснить на какие еще неправильные права доступа жалуется система.
В итоге, после описанных действий команда sudo заработала, теперь уже без всяких ошибок и предупреждений. Если у вас, как и у меня были изменены рекурсивно права доступа на весь корневой раздел, то после этого лучше вручную установить нужные права на все критически важные файлы и папки. Или поискать в сети способ поизящнее. Ну или переустановить систему =)
>>sudo chmod 777 –R /some/folder
после чего, у меня оказались переписаны права на каталог с sudo (/usr/lib/sudo и на несколько других) и я больше не мог действовать от имени суперпользователя (оужас!). Произошло это оттого, что в папку, на которую я менял права, был примонтирован корневой раздел системы, упустив этот момент я по глупости переписал права на все файлы.
При попытке выполнить какую-либо команду от рут-пользователя появлялось сообщение о том, что «sudo: /usr/bin/sudo должен принадлежать пользователю с uid 0 и иметь бит setuid». (Для справки: как правило, root–пользователь имеет id, который равен 0, но здесь это не играет роли)
Пошарившись немного в сети, решения так и не нашел, по крайней мере, все предлагаемые мне не подходили. Большинство тем с такой же проблемой на форумах заканчивались просто перестановкой системы. В силу моего упрямства это тоже был неприемлемый вариант.
Выход для моего случая заключался в перезагрузке в Recovery Mode и последовательном выставлении необходимых прав на папки, в которых содержатся жизненно важные команды, потому что система ругалась на неправильные права на эти папки и файлы.
Чтобы попасть в Recovery Mode в загрузчике нужно выбрать пункт «Дополнительные параметры для Ubuntu», затем строку с Recovery Mode и в меню выбрать root:
Теперь можно действовать из-под рут-пользователя.
Перед любыми изменениями необходимо сначала перемонтировать файловую систему с возможностью не только чтения (как она примонтирована по умолчанию в режиме восстановления), но и для записи:
#mount –o remount , rw /
Затем меняем права на файлы папки.
Можно сверять данные права доступа на файлы/папки с другой системой, если есть под рукой (Я так и делал)
Для начала не помешало бы вернуть корневому разделу более менее приемлемые права доступа (эту команду изменения прав доступа для корневого каталога следует использовать только если ранее были изменены права доступа ко всем файлам и папкам, а не к отдельным), например:
#chmod 0755 –R /
Для /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), чтобы выяснить на какие еще неправильные права доступа жалуется система.
В итоге, после описанных действий команда sudo заработала, теперь уже без всяких ошибок и предупреждений. Если у вас, как и у меня были изменены рекурсивно права доступа на весь корневой раздел, то после этого лучше вручную установить нужные права на все критически важные файлы и папки. Или поискать в сети способ поизящнее. Ну или переустановить систему =)
@темы: ubuntu
