Комментарии 19
Старший бит это биты setuid и setgid.
Бит - это биты. Какая-то не очень удачная формулировка... таки "старший байт содержит/хранит/включает биты setuid и setgid", вероятно?
А можно ли починить систему?
Теоретически да, но скорее в очебных целях.
ЕМНИП, на самом деле можно сделать это относительно безболезненно в некоторых дистрибутивах из коробки идёт пакет содержащий в себе файлик со списком прав на ключевые для системы файлы и директории, и скрипт который парсит и применяет их. Ну и наверное полная переустановка всех пакетов тоже всё пофиксит на уровне системы, а вот в хомяках и data директориях некоторого софта придётся прибраться руками..
в некоторых дистрибутивах из коробки идёт пакет
а можете написать пример такого пакета? быстрым поиском гугла я не нашел ничего подобного
откат на существующий backup
А ещё пользователь не так давно перешёл на GNU/Linux, сделал свой бэкап ранее в криптоконтейнер, например, Veracrypt (том fat32/ntfs). Права все утеряны. Система восстановлена, но не работает. Фэйл.
На полноценную статью материал не очень тянет, плюс орф.ошибки.
Да, жизненно. Сделал так по юности на удаленном сервере, думал что безопасность не так критична, а не заморачиваться с правами сэкономит кучу времени. Спас бэкап, который удачно был снят не за долго перед этим. Второй подобный эпичный раз был немного позже, когда я выполнил chmod -R 777 на свою домашнюю директорию что бы nginx мог запускать из нее скрипты, и с удивлением обнаружил что больше не могу зайти по ssh. Благо там был добрый админ, который пообещал оторвать мне руки, и отобрать права на все сервера пока не соберу сам linux from scratch.
Хороший материал может получиться, если продолжить опубликованное вступление.
Уверен, что полезная для многих тема.
Меня чуть разочаровала краткость. Я был готов воспринять какие-то более глубокие ньюансы, с которыми раньше не сталкивался.
Не 0 777, а на на самом деле 00 777.
Но если копнуть больше, то обнаужим, что место зарезервировано для 8 разрядов.
Р.S. Вспоминая Федорчука и нынешний "контент" :(((
Пожалуй, действительно, можно было бы развить эту тему. То, что эта команда сломает чуть более чем всё - нет возражений. Но можно было бы и попробовать восстановить систему - это было бы более полезно.
rm -rf / или куда делись мои файлы
неосторожное обращение с ,казалось бы, известной нам командой может привести к большому количеству проблем.
Неосторожное обращение - это права администратора у неграмотного пользователя.
С админским доступом, поломать систему можно и более простыми способами, чем запускать консоль и вводить там команды...
Фигня, без sudo ничего не случится. Вы же не логинитесь под рутом на сервер? :)
Я логинюсь, лет 25 уже как. Потому что в 99.9% случаев когда я логинюсь мне нужны права рута — и за всё это время ни одного фейла, как ни странно.
Как обычный пользователь я логинюсь только для сборок, разработки, офисых задач (под иксами) а также в случаях когда что-то в песочнице нужно погонять, или если у клиента нет рутовских прав (или они не нужны).
Вообще непонятно откуда эта мантра "не логинтесь как рут" — разве что для чайников (как слабая защита от фейлов), потому что даже во времена telnet на небезопасной сетке sudo/su не спасало от прослушки и последующего вредительства.
Впрочем, как показывает практика, от любителей стрелять себе в ногу не спасают даже бронештаны с бронеботинками — если человек не знает что делает, не выспался, или тупо повторяет инструкции шутников, в этом случае его всё равно не спасёт логин обычным пользователем если команда требует sudo.
без sudo получить рутовый доступ в нормальной системе можно только в single режиме. Ибо пароль у рута должен отсутствовать по определению.
На Хабре уже есть замечательная статья о правах доступа
О какой именно статье речь? можно пожалуйста ссылку
chmod -R 777 / или почему ничего не работает